Creating a new payment integration

We can set up integrations with payment processors that are new to the product. This will require an implementation project with our teams, and likely additional cost. Deployment of existing integrations to your govService site is much faster and more affordable than creating a payment integration that is new to the system. For more information on implementation times and associated costs, please contact your Account Manager or Customer Success Consultant.

What you will need

You will need all of the following information at hand to set up a payment integration for your site with any payment processor, existing or new to govService:

• Full documentation of the interface to your payment gateway
• Merchant information
• Connection details to a test site available on the internet (hosted by payment gateway or the customer)
• Sample card details so we can test transactions
• Sample fund codes/GL codes etc for a suitable test transaction
• A contact at your organization who can verify the status of test transactions we submit

The working integration will then be enabled on your platform and documented.

govService will build the connector specifically to the vendor, type and version.

Examples of payment integrations

The following is a partial list of integrations already in place. Please let your Customer Success Consultant or Account Manager know if you need us to integrate with a payment processor that is not listed.

• Adelante
• Capita
• Cardsave
• CashNet
• Civica
• DataCash
• FuturePay
• Gov.uk Pay 
• Netbanx
• Paris/Paris MOTO
• PayDirect
• PayOffshore
• PayPal
• Paypoint
• Widle
• Xpay

How the integration functions with Forms

Payments in Forms use a standard integration which can work with a range of 3rd party payment systems by using a connector created by govService programmers.

The sequence of actions when a Form is being designed

• The form designer creates an integration of the type 'Payment'.
• The form designer selects the system with which the payment will integrate from a predefined list. This list is configured by Granicus for your site.
• The form designer provides some standard values (such as a live test indicator) and some JSON for other details that the payment connector uses. These values can use form tokens as required.
• The payment integration can then be added to any form.

The sequence of actions when a Form is being filled and submitted

• The form filler submits the form as normal.
• Instead of showing the confirmation page, Forms performs an HTTP request to the payment processor, passing in JSON that uses tokens from the form to set up the transaction.
• The connector prepares a redirect. For some payment processors (e.g. Capita v8+) this involves calling one of their web services to setup the transaction, but with many systems the redirect can be prepared using only the supplied JSON.
• The connector returns the redirect page to Forms in its response.
• Forms returns the redirect to the form filler.
• The form filler is redirected to the 3rd party payment system, enters their card details, etc.
• The form filler is returned to the connector by the 3rd party system. This should occur before the customer has seen confirmation of a successful payment, to reduce the risk of an abandoned transaction.
• The connector checks the status of the transaction. For some payment processors (e.g. Capita v8+) this involves calling their web service, but with many systems all of the necessary information was provided with the redirect. The connector then redirects the form filler back into Forms, encoding the results of the payment into the redirect using a private hash.
• Forms then displays either the confirmation page (including the payment transaction reference if the transaction was successful) or an error page with the option to return to the form (if the payment was unsuccessful).

Note: Test assistant cannot be used for payment integrations