Skip to main content

Handle the payment result

After submitting a payment, your integration needs to determine the current state of the transaction and handle the result appropriately.

The payment status returned immediately after submitting a payment is not always the final status. Depending on the payment flow, the transaction may still be processing or may require additional customer interaction.

Revup provides several ways to obtain updated transaction information:

  1. The payment API response.
  2. A callback to the configured redirect URL.
  3. Notifications sent when the transaction state changes.
  4. The Transaction API, which can be used to retrieve the latest transaction information.

Payment result flow​

1. API response​

When a payment is submitted, Revup returns an API response containing information about the transaction, including its transaction ID and current status.

The response allows your integration to determine whether the payment has already succeeded, failed, or is still being processed.

However, the status returned in the initial response may not be final.

This can occur with:

  • Asynchronous payment methods.
  • Payments where the acquirer has not yet returned a final response.
  • Payments that require additional customer interaction, such as 3D Secure.

For this reason, your integration should not assume that a non-final status represents the final outcome of the payment.

2. Callback to the redirect URL​

Revup can send the customer back to the URLs configured for the payment through the redirectUrl configuration.

The redirect URLs can be configured:

  • Statically in the merchant configuration.
  • Dynamically when creating the order.

The configuration contains a success URL and a fail URL.

When the payment is successful or still in process, Revup redirects to the success URL.

When the payment fails, Revup redirects to the fail URL.

The callback contains transaction information with a more updated status than the initial payment response.

warning

A redirect to the success URL does not necessarily mean that the transaction has reached a final success status.

The transaction can still be in_process, for example when the payment is asynchronous or the acquirer has not yet returned a final response.

Always use the transaction status to determine the actual state of the payment.

Multiple transactions​

The callback can contain one or two transactions.

Two transactions can be returned when the first payment attempt fails and a fallback MID is used to process the payment.

If multiple transactions are returned, your integration should keep track of all the transactions reported by the callback.

For the callback payload and available fields, see the Callback to redirect URL reference.

3. Notifications​

A transaction can change state after the initial payment response or redirect callback has been received.

Revup can send notifications when the transaction state changes.

Notifications are sent to the notificationUrl configured for the merchant.

The notificationUrl can be configured:

  • Statically in the merchant configuration.
  • Dynamically when creating the order.

Notifications are particularly important for asynchronous payments and payments requiring additional processing, because the initial payment response may not contain the final transaction status.

For more information about configuring and handling notifications, see Notifications.

4. Retrieve transaction information​

Your integration can also request the latest transaction information from the Revup API.

This can be useful when:

  • The initial payment response contains a non-final status.
  • You need to verify the current state of a transaction.
  • Your system needs to reconcile a payment.
  • You need to retrieve updated transaction information.

Revup provides transaction endpoints that allow you to retrieve transaction information using the transaction ID or the order ID.

For the available endpoints and response fields, see the API reference.

Transaction statuses​

The following statuses indicate the state of a payment:

StatusFinalDescription
successYesThe payment has been processed successfully.
failedYesThe payment has not been processed successfully.
in_processNoThe payment is asynchronous and is being processed, or the payment is synchronous but the acquirer has not yet provided an answer.
waiting_user_interactionNoThe payment is being managed by the 3DS process or APM and requires customer interaction.

success​

The payment has been processed successfully.

This is a final transaction status.

Your application can consider the payment completed once the transaction has reached this status.

failed​

The payment has not been processed successfully.

This is a final transaction status.

Your application can handle the payment as unsuccessful according to your business logic.

in_process​

The payment is still being processed.

This is a non-final status and should not be treated as a successful or failed payment.

The transaction may be asynchronous, or the payment may be synchronous while the acquirer has not yet returned a final response.

Your integration should wait for a subsequent transaction update, such as a notification, or retrieve the transaction information again when appropriate.

waiting_user_interaction​

The payment requires additional customer interaction.

This status is associated with the 3DS process or APMs.

The customer may need to complete an authentication step before the payment can reach its final state.

Your integration should allow the required customer interaction to take place and then use the subsequent transaction status to determine the final payment result.

A typical payment result flow should follow these principles:

  1. Submit the payment and inspect the API response.
  2. If the transaction is success, treat the payment as successfully processed.
  3. If the transaction is failed, treat the payment as unsuccessful.
  4. If the transaction is in_process, do not treat the payment as final.
  5. If the transaction is waiting_user_interaction, allow the customer to complete the required interaction.
  6. Use callbacks and notifications to receive subsequent transaction updates.
  7. Retrieve the transaction from the API when your integration needs to verify or reconcile its current state.
info

The API response, redirect callback, notifications, and Transaction API provide transaction information at different points in the payment lifecycle.

For asynchronous payments and payments requiring 3DS, use the subsequent transaction updates to determine the final state rather than relying only on the initial payment response.

Applicable payment flows​

The payment result handling described in this section applies to the different Revup payment flows.

It can be used with:

  • One-off payments — determine the result of the single payment.
  • Token-based payments — determine the result of the initial or subsequent transaction.
  • Subscriptions — determine the result of the initial payment and monitor subsequent recurring payment events.

The way the payment is initiated may differ between these flows, but the transaction status and mechanisms used to obtain updated transaction information remain part of the payment lifecycle.