What are the typical advantages to govService clients?
The key value is improving the customer experience. By having the payment connector in place you can deliver a seamless and easy experience that covers both the service process and the payment.
Customers can design any form to use with the same payment connector. This way you have continuity with your other online e-Forms as well as the advantages around ease of build, customisation, accessibility and reporting.
Once this connector is established, it is available as an integration action which can be used in any number of e-forms that require a payment. Our customers typically are able to do this with no involvement from Granicus once the integration is in place and demonstrated on a test form.
All the information about the payment is stored within the Platform (what the user ordered and whether the payment was successful or not), however we do not hold the card details. The council does not need to check in disparate systems for the details of the order and the payment status.
What is the typical end-user experience?
The customer journey is practically seamless - you can use the form to capture contact details plus anything else pertinent to the enquiry (including what it is they want to pay for) and calculate the costs. The information relevant to processing the payment can be seamlessly and securely posted to the payment portal without the need for the customer to re-key the info. The payment portal takes the secure payment details before passing the customer back to the form for completion. The process works like this:
- The form filler will complete the online form and click the 'Submit' button, which will typically be relabelled to 'Pay'. The last section of the form will normally include a summary of what must be paid, and explain what is about to happen.
- On clicking the submit button, they will be redirected to the payment system which will confirm the amount to pay and prompt for the card details. The payment system may also populate the customer's address and contact details, and more details about the transaction using data from the online form. With online transactions the card details entry will typically involve "3D Secure" interactions with the bank or card company.
- On entering their card details and choosing to 'Pay', they will be redirected back to our system immediately - there is no confirmation screen shown by the payment system
- If the payment was successful, they will see a confirmation screen that includes both the payment transaction and Forms reference numbers, plus any relevant message set by the form designer. In addition, the form is regarded as submitted - it is not possible for the form to be submitted if payment was not made. If the payment was not successful, they will receive an appropriate error message and be directed back to their form, which has not been submitted.
What needs to be done to each form that takes a payment?
- Ensure the last section of the form, the confirmation screen, and the submit button caption all contain appropriate help text for the form filler.
- Ensure there are fields on the form which hold the amount to be paid and the fund/ledger code to be credited.
a) Some payment systems can accept more details, such as customer address, email, and information about each item being purchased.
b) For integrations that involve multiple items, each can have an amount, description and fund/ledger code.
c) Some payment integrations can also accept in an indicator to distinguish between self-service-online transactions and mediated 'cardholder not present' transactions (MOTO, Mail Order Telephone Order).
- Add a 'Pay' integration action, based on an example our consultants will setup for you (or documented on this wiki). Ensure it uses the correct references to the fields on your form. Payment integrations can have conditions added to disable payment if it is not required (e.g. if amount>0).
What happens if the user abandons the payment?
The user's form data is retained in the system and may be located and marked as paid via an admin screen.
A small minority of payment systems are susceptible to a user completing a payment transaction but the notification to the govService system is missed. Such systems typically have a separate confirmation screen that is shown to the user thanking them for their payment and prompting them to return to the govService system. This is often regarded by the user as confirmation that the form has been submitted, and so they do not follow the prompt. The simplest way to deal with this issue is to use an automated redirect. In many cases the payment integrations involve direct exchange of information with the govService system in addition to the user redirection, and so this situation cannot happen. (Though there can be similar issues with some payment systems which do not time out if the form filler takes a long period of time to complete the payment stage, the payment maybe taken and the form submission itself times out for security reasons, however these occurrences can be traced)
Does the solution support the approach of a single form using the same payment integration published in all channels? If so how does it know how to handle the transaction differently?
Yes. Our platform uses permissions to understand who is completing the form. It is a simple matter of the re-usable form template we provide adding a calculation that returns the right value to corresponding parameter in the payment portal. (customer present) or MOTO (not present). We advise our clients to check with the portal provider this functionality is enabled.
Can the information exchange be tampered with?
Most modern payment systems use hashing algorithms and/or direct server to server communication in addition to the browser redirects in order to ensure that the two systems can exchange details of the transaction in confidence. Some older system interfaces do not support these concepts, and may have a theoretical vulnerability - see your payment provider for details. We provide full support for any security mechanisms exposed by the payment system you wish to integrate with, including server side amount validation.
Can the integration be hacked to create malicious redirects to spoof payment services?
No. The destination of the redirect to the payment site is specified by the form designer and cannot be overridden by the client. Our software is frequently subject to penetration testing and is secure against attacks, including but not limited to XSS vulnerabilities, script injection, html injection and SQL injection. Our code review system includes checking newly-developed code against such concerns.
Does Granicus need to be PCI DSS compliant?
No, Granicus does not fall under the legislation as our solution doesn’t hold or take secure payment information. We do ensure that the integration is secure.
Which providers can govService Integrate with?
We can integrate the Platform with just about any 3rd party gateway. Granicus must build the connector specifically to the vendor, type and version but the techniques involved are similar for each one.
Note: In the United States, govService has existing integrations for the following payment processors:
- Stripe
- Authorize.net
- Heartland
What happens if my payment gateway provider changes API?
If you have a support agreement which covers the connector Granicus will update our connectors to fix the issue.
What happens if I changed payment gateway provider?
You will need to buy additional consultancy to build/deploy a new connector, but you can retain the same annual support agreement.
Diagram of the Service
NB Web Service Payments are not supported on our cloud service as we cannot capture card details on our servers, even transiently.
Technical Information
The payment integration gets run at the 'Pre Submission' status in the Forms process. A HTML form is generated, with substituted form data from the form (amount and various user information). This form is then automatically submitted and the HTTP POST action is called to the payment provider, sending the values and the user to the payment portal on that action. A derivative also exists with the Capita Payment Portal with an XML Post method.
Further notes:
The most crucial benefit for Form Post integrations is that the integration is able to make use of the return information from the payment provider and feed that back into the user's submission. If a payment integration used a standard HTTP Post integration to send the information to the payment site, there could be no record of whether this payment was actually taken or whether the user just closed their browser after arriving at the payment portal. Using the govService-supported integration module allows a Form to integrate with payment portals tightly to ensure it knows that the payment was successfully taken and that this information (including the payment reference) is recorded against the form submission.
govService is able to make use of all the security features that are provided by the payment provider. This is often in the form of a call back from the payment provider. This secure callback is made by the payment portal site to Forms and will include the payment success information before the user gets redirected to the form. When the user gets redirected, Forms will be able to associate the callback information with the specific form submission.
