Payment Reconciliation
This guide details how Aurora reconciles payment requests to ensure all transactions registered within your payment provider are accounted for within Aurora.
Introduction
Due to the implementation of HCC by some payment providers, such as Realex, there are scenarios whereby payment may be taken without visibility within Aurora. These scenarios can occur where a user progresses through payment and is either not returned to Aurora by the payment provider or the payment provider returns an incorrect response.
The Aurora Payment reconciliation process attempts to query the payment provider for all known payment sessions in order to identify orphaned payments that are not visibly within Aurora or that require action.
How does the payment process work?
When a customer submits the Aurora checkout or multi-payment UI and progresses through final payment, a new payment session is initiated and logged within Aurora as a payment request. Each payment requests contains a unique identifier, which is normally an Aurora order ID.
The customer is then presented with a payment UI rendered directly by the payment provider, either as a full page or within an iframe.
Once the customer has entered their payment details and submitted a request to the payment provider, they are redirected back to Aurora with a payment response.
Aurora then processes the payment provider response to determine whether payment was successful, confirms that the basket has not changed during the payment process and either creates a failed order and redirects the user back to the checkout process or creates a live order and redirects the user to order completion.
In either scenario, Aurora will register the payment response as a payment transaction against the failed or live order.
Depending on how your payment provider integration is configured, Aurora may automatically take further action to then release and/or void payments based on payment type (i.e. Payment, Deferred etc.) or error type (i.e. the basket has changed during payment, failed fraud results etc.)
Please see the payment provider integration documentation for more details about payment types, fraud result processing and payment voiding.
What can cause orphaned payments?
There are several scenarios that can cause orphaned payments, but essentially these are caused when a user progresses through payment and is either not returned to Aurora within the session timeout period or not returned to Aurora due to an error within:
- The payment provider
- The acquiring bank security process i.e. 3D Secure
- The users browser i.e. JavaScript error or blocker
- The HTTP connection
Known Scenarios
Session Timeout
Sessions are a mechanism of allowing information to be stored and retrieved between multiples requests to an application such as Aurora. When the users browser makes a request or submits information to Aurora, either an existing session is retrieved or a new session is created and a timeout period initiated. If the user has not made a subsequent request within the timeout period, the session is automatically expired and all information stored within the session is removed.
The session timeout period length directly affects server resources and can affect application performance.
Please query your Aurora account manager for the session timeout period on your instance of Aurora.
The session timeout period for some payment providers can exceed the Aurora session timeout period and as such can lead to a scenario where a user is returned to Aurora outside the timeout period, in which case the checkout details are no longer available and Aurora has no reference as to how the request should be handled.
This scenario can occur where there is latency within the payment provider system or a user begins the payment process and then completes payment several hours later.
3D Secure Double Submission
When a user enters payment details within the payment providers UI, they may then be redirected by the payment provider to a subsequent security UI (i.e. 3D Secure) which in some cases is managed by the acquiring bank.
If the security UI does not protect against multiple submissions (i.e. the user clicks the submit button more than once) the payment provider can receive multiple requests to complete payment, which if the payment provider does not accommodate, can result in Aurora receiving an unsuccessful payment response where payment has actually been taken.
Browser JavaScript Error or Blocker
When a user successfully completes payment, the payment provider instructs the users browser to submit a payment response back to Aurora. In someone circumstances this can be unintentionally blocked by a browser scripting error or actively blocked by a browser security protocol.
For this reason, we advise clients to provide a manual HTTP submission process as a backup to any script driven auto-submitting process.
How does the reconciliation process work?
The Aurora payment reconciliation process is a completely separate automated process that is executed every 15 minutes and will process all payment requests registered within Aurora in sequence.
Where a payment request cannot be resolved to a live order, Aurora will query the payment provider requesting details of any successful transactions associated with the payment request unique identifier (i.e. the order ID).
Where there is no payment transaction associated with the payment request, no action is taken and the payment request is marked as reconciled.
Should an orphaned payment transaction be identified, Aurora will first attempt to correlate the transaction to an existing failed order or created a new failed order accordingly.
The orphaned payment transaction is then cross-referenced with any existing failed order transactions to determine whether the orphaned payment transaction has already been handled.
Where the orphaned payment transaction has not already been handled, Aurora will take action.
What action does the reconciliation process take?
Where an orphaned payment transaction is identified as requiring action, Aurora will attempt to automatically void the transaction.
The void process can be different based on the type of payment (i.e. Payment or Deferred) and the payment providers batching process.
Some payment providers, such as Realex, advise that Deferred payments are always released and refunded, rather than voided, to ensure that the shadow authorisation registered against a customers bank account is removed.
Voiding a Deferred payment would require the customer to contact their bank account in order to have the funds released or wait 30 days for the authorisation to expire.
Please see the Realex Payments guide for further information.
How long does it take for Aurora to void payment requests?
Although the reconciliation process runs every 15 minutes, only payment requests older than 26 hours will actually be reconciled. This is because the payment provider HCC solution session timeout period can be up to 24 hours, which means a customer can start the payment process and potentially complete payment up to 24 hours later. This means that a user may leave Aurora to complete payment and not return for up to the payment providers session timeout period, in which time if Aurora were to attempt reconciliation of the payment request, it would be unsuccessfully reconciled and orphaned transactions could be missed. In addition to this, Aurora allows a further 2 hours to account for time zone changes throughout the year (i.e. BST).
In addition to this, should Aurora take action to void a payment transaction, due to the nature of the void process when dealing with some payment providers such as Realex and needing to release and refund payment transactions in order to avoid leaving shadow authorisations on the customers account, a refund will be scheduled to be actioned once Aurora is certain the payment transaction has been batched (i.e. sent to the bank by the payment provider).
To add further delay to the process, the payment provider will often not return the date or time of the original payment transaction within the reconciliation query response and as such Aurora must assume that the payment transaction has only just been created and in turn schedule the refund for after the next batch processing time.
Aurora can take up to 48 hours from the original payment request time to actually refund a payment transaction that has been identified as requiring reconciliation.
The payment provider can then take a further 24 hours to actually batch process the refund request before the refunds are returned to the customers account.
Updated almost 2 years ago