Handling Results

After initiating a Hosted Checkout session, you’ll need to update your system with the result — whether that’s a completed payment, stored payment credentials, or the creation of a Variable Recurring Payment (VRP) mandate.

There are three ways to retrieve this information:

1. Form POST Callbacks – Data posted back to your return URL after checkout completes.
2. Webhook Notifications – Real-time push updates sent to your configured endpoint.
3. Polling the API – Requesting the latest status manually via the API.

⚠️

We recommend implementing logic to handle webhooks and Form POST Callbacks as your primary method and using polling as a fallback for redundancy.

Best Practises

To ensure reliability:

• ✅ Use webhooks as your primary status update mechanism.
• ✅ Use form POST callbacks for immediate client-side updates, but never as your sole source of truth.
• ⚪ Use polling only as an optional fallback when you need to confirm a status on-demand (e.g. before fulfilment or if a webhook fails).

Form POST Callbacks

When the user completes payment, they are redirected to a payment outcome page. This outcome can be shown directly by Acquired.com or you can handle the redirect on your own site.

If you use Acquired.com’s hosted payment outcome screens, customers will see a success or failure message.

• If you use Acquired.com’s hosted outcome screens, customers will see a success or failure message.
  • If a redirect_url is configured, a “Return to merchant” button links them back to your site.
  • If no redirect_url is set, there will be no way back to your site.
• If you handle the redirect yourself, Acquired.com will send a form POST to your redirect_url in application/x-www-form-urlencoded format.

Handling the Customer Redirect

So that you can present customers with the payment status, Acquired.com will send a form POST to the redirect_url in format application/x-www-form-urlencoded.

Always present fields

Here are the fields that will always be present in the Form POST:

Example payload:

status=executed&transaction_id=1970f4e1-95da-4859-b275-e9ac83f05eb1&order_id=your_unique_reference_1&order_active=false&timestamp=1657183950&hash=d201a2ed66573043ff0b210de295c3d565b70aa1ffb35534bd29ce77a5987f14

Conditional fields

Some fields are only included in specific scenarios:

• mandate_id is included only in Pay by Bank (VRP) scenarios.
• If your integration accepts VRPs alongside other payment methods, you must ensure it can correctly process both VRP mandate callbacks and standard payment callbacks, since customers may choose either flow within the same Hosted Checkout session.

Example VRP payload:

status=active&transaction_id=&mandate_id=4568bb6c-ae89-42e0-83e6-ad5fadc598da&order_id=your_unique_reference_1&order_active=undefined&timestamp=1657183950&hash=d201a2ed66573043ff0b210de295c3d565b70aa1ffb35534bd29ce77a5987f14

Verify the integrity of the form data

A hash value will be calculated every time a customer is navigated to the redirect_url. This allows you to guarantee the authenticity of the data.

To do this, generate a new hash value and compare it to the returned hash value. If the hash values match then the data has not been altered and the origin and integrity of the data has been verified.

To calculate the has value, you'll need to do the following:

1. Concatenate the parameters in this order: status . transaction_id . order_id . timestamp

     `executed1970f4e1-95da-4859-b275-e9ac83f05eb1your_unique_reference_11657183950`

2. SHA256 encrypt the resulting string.

     `4e9ce34004008830e672aa826efd5ddf56130ad127c279751135d48291b5f007`

3. Append your app_key value to the hash value of a string.

     `4e9ce34004008830e672aa826efd5ddf56130ad127c279751135d48291b5f007app_key`

4. SHA256 encrypt the resulting string again.

     `4e7e127a6ab8e7c4d73100e0c959eb42e1d61adff6b641c6ea7e4690e44cbff0`

5. Compare the generated hash value to the previous returned hash value.

Webhook Events

The table below outlines the key webhook events you may receive depending on the payment method and Hosted Checkout scenario.

See also: Webhook Notifications Guide for configuration, retries, and verification details.

Idempotency and Multiple Transactions

In Hosted Checkout, it’s possible for more than one transaction_id to be created against the same order_id. This can happen if a customer reopens a payment link or retries a payment. While multiple transactions may exist, only one can be marked as successful for a given order_id.

Merchant handling requirements:

• Support multiple transactions perorder_id – your integration should track each transaction_id separately.
• Determine the final order status by evaluating all transactions linked to the order_id.
• Apply payment method–specific logic when interpreting webhook sequences (e.g. Cards vs Pay by Bank SIP vs Pay by Bank VRP).

Polling the API for Transaction Status

As a fallback, you can poll the Acquired.com API to retrieve the latest transaction status. This can be useful in scenarios such as:

• Webhook delivery failures
• You need to confirm a status before order fulfilment

Since the transaction_id is not known until you receive either a webhook or a Form POST, you can instead query the status using the order_id value passed in your original /payment-links request.

Example:

GET /transactions?order_id=your_unique_reference_1

The response will include the current status of the transaction. You can find more information about the response fields in the Retrieve a Transaction API reference.