Introduction
A payment integration usually involves a seamless transaction from form submission to capture payment details and then a successful hand shake to the form to confirm that payment has been successful and the form can be completed in full.
However there are some cases where a payment has been successful but a response has not been returned to the firmstep platform, and in these cases we are unable to associate the payment to the case.
What is an Abandoned Payment?
'Abandoned Payments' or 'Failed Payments' are terms we use to refer to the following use cases:
- Cancelled Payments: this is when the user manually cancels their payment whilst in the payment provider screen, and fails to successfully submit the form as a payment must be taken. This results in no case being created but as no payment was taken, there does not need to be a case.
- Payment Error: this is when an error occurs in the payment provider and an error code is returned by the payment portal. For example, if the user has not got enough money to pay the amount, and they therefore cannot return and successfully submit the form. This results in no case being created but as no payment was taken, there does not need to be a case.
- Payment is not made and the user does not return to the form: for example, the user closes the tab or browser before they complete the payment. This can be reduced by switching on the payment landing page. This results in no case being created but as no payment was taken, there does not need to be a case.
- Payment is made successfully and the money is taken from the user's account, but the user does not return to form: for example, the user closes the tab or browser before they complete the payment or their session times out before they return to the form. This results in a payment having been made but no case is ever created - this is problematic if a user has paid for a service but does not receive confirmation or a second task is not created from submission of the first.
At this point the workflow stops, a save is generated in our temp bucket, but the case has not been progressed to completion.
Without manual intervention the case remains in limbo and the service request or purchase is not actually made, and the customer may soon contact the council to ask why they have not received a paid for service etc
Auto reconcilation - is now available for a number of payment connectors and will reduce the number of abandoned payments
Payments Admin
To access payments admin you must have the access payment role applied to a group you belong to, the payment admin option will then be available from the admin menu.
Confirmed payments
The payments admin screen allows you to "confirm" that a payment was made and to manually attach the case to the payment and thus continue the form submission - to fire any relevant integrations and to move the case to the next valid stage.
First you will need to choose a date the payment took place on by using the date box displayed below, to display all payments abandoned on the given date (you can sort the results list as required).
The reference number and the form name can be used to cross reference to the payment transaction from your payment system, if the form was completed anonymously then no user details will be present.
The Payments Admin screen will show details about the process stage and any error message that was returned
on selecting Process the payment admin screen allows the user to set custom values for the transaction reference and other custom parameters to use in the submission, which would have been passed by the payment process itself and maybe required in subsequent integrations that run on submission etc. It does not process the transaction at this stage, see below
Note: non-platform url parameters need to be prefixed with data_ these are a byproduct of the extra return parameters of a number of payment connectors.
Civica and Capita allow a user to specify as part of the payment payload a number of additional parameters that can be returned when a transaction is complete eg a common one is the receipt number. This is a particular reference specific to the Capita environment that can be used for tracking VAT or other transactions as necessary. Normally its not possible to return this to the Forms product, however when returning from a payment we look at url parameters and any of the parameters that are prefixed with data_ get pulled back in to the form, but specifically we only populate top level fields with the dataname WITHOUT using the prefix data_
eg if the url parameter is data_receiptNumber then we will populate receiptNumber with its value, but not subform1/receiptNumber or data_receiptNumber. This parameters section of the payments admin is to facilitate the processor populating those values even when the forms Product does not have that data.
Once you have corrected any of the parameters required, the abandoned payment can then be resolved using the process button which will manually mark the case as paid , after a few seconds the reference will be marked as completed and removed from the list.
This process resumes the submission resulting in the all the submission integrations be run.
The Submission will then be displayed within view data and relevant dashboards as applicable
Note: This will not re-run the payment.
No Payment
In cases where local checks have revealed that the customer DID NOT make a valid payment for the service/purchase - then you need to decide whether it is correct to process the transaction in the payment admin option. In majority of cases where a payment has not been made then it would be incorrect to process the transaction within the Payment Admin - as this WILL run any integrations etc unless you have mechanisms in place to prevent - see below;
- Can I stop integrations running on the submission
Historically the transaction reference was always REF/FSPA-NEW, in the current version of the payments admin this is only true if the transactionReference parameter isn't set when reconciling. So if this reference is not set/deleted before processing, it would be possible to add a condition to the process to not run the integrations, though this scenario is unlikely - why would you want to submission to exist if the payment had not be taken?
(The log in the payment admin shows that a payment COULD have been taken, but the platform is unaware of the payment, by processing the failed transaction you are in essence saying the payment was made)
Note: at present there is no way to delete the cases in these situations, but where payment admin is handled in chronological order - older dates can simply be ignored as part of local process.
Checking Payments
The checking of whether a valid payment was actually made has to be a manual process, using your payment system and accounting for any payments that may be made via other routes eg telephone payments, bank tx or cheques etc. However the Auto reconcilation - is now available for a number of payment connectors which will reduce the number of reported abandoned payments.
top of page
Further useful reading:
