Notifications

Revup notifications allow your backend to receive updates whenever the status of a transaction changes.

Notifications are sent to the notificationUrl configured for your merchant account or for the order.

Unlike the payment callback, which is used as part of the initial payment flow, notifications are sent whenever a transaction changes state.

This makes notifications the main mechanism for keeping your backend synchronized with the current state of transactions.

How notifications work

The notification flow is independent from the customer's payment flow.

When a transaction changes status, Revup sends a notification to the configured notificationUrl.

The general flow is:

A transaction can generate multiple notifications during its lifecycle because its status can change more than once.

For example, a transaction may initially be in_process and later change to success or failed. Revup sends a notification when each relevant status change occurs.

Notification URL

Notifications are sent to the notificationUrl configured for the transaction.

The URL can be configured:

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

Your notification endpoint must be publicly accessible so that Revup can send HTTP requests to it.

The endpoint should be prepared to receive Revup notification requests and process the transaction information included in the payload.

Notification lifecycle

A notification is generated when the transaction status changes.

For example:

1. A transaction is created.
2. The transaction enters in_process.
3. Revup sends a notification.
4. The transaction is processed by the acquirer.
5. The transaction changes to success.
6. Revup sends another notification.

The number of notifications depends on how the transaction progresses through its lifecycle.

info

Notifications are not limited to the initial payment.

They can also be sent for subsequent token-based payments and recurring payments generated by subscriptions whenever their transaction status changes.

Notification vs. callback

Notifications and callbacks serve different purposes and should not be treated as interchangeable.

	Callback	Notification
Purpose	Return information to the payment flow	Notify the merchant about a transaction status change
When it is sent	As part of the initial payment flow	Whenever the transaction status changes
Destination	Redirect URL configured for the payment	notificationUrl
Customer involved	Yes, the customer can be redirected	No
Can occur multiple times	Part of the payment flow	Yes, whenever the transaction changes state
Recommended use	Update the customer's checkout experience	Synchronize the merchant backend

The callback is useful for updating the customer's browser or checkout flow after the initial payment.

Notifications are intended for server-to-server communication and should be used by the merchant backend to keep its internal payment state synchronized with Revup.

warning

Do not rely exclusively on the callback to determine the final state of a transaction.

A transaction can change state after the callback has been sent. Your backend should process notifications to keep the transaction state up to date.

Processing notifications

When your notification endpoint receives a notification, your backend should:

1. Receive the notification request.
2. Identify the transaction.
3. Read the transaction status.
4. Update the corresponding payment in your system.
5. Apply any business logic associated with the new status.
6. Return the appropriate HTTP response.

Your system should be able to process multiple notifications for the same transaction because a transaction can change status more than once.

For example, your database may initially record a transaction as in_process and later update it to success after receiving the corresponding notification.

Transaction statuses

Notifications can provide updates for different transaction statuses.

The main statuses used by Revup include:

• success
• failed
• in_process
• waiting_user_interaction

Your backend should interpret the status included in each notification and update the transaction accordingly.

success

The transaction has been successfully processed.

Your backend can mark the corresponding payment as completed.

failed

The transaction has not been successfully processed.

Your backend can mark the payment as failed according to your business logic.

in_process

The transaction is still being processed.

This is a non-final state. Your backend should keep the payment in a pending or processing state until a subsequent notification provides the final result.

waiting_user_interaction

The transaction requires additional customer interaction.

This status is associated with the 3DS process.

Your backend should not treat the transaction as successful until a subsequent status indicates that the payment has been successfully processed.

Notifications and asynchronous payments

Notifications are particularly important for asynchronous payment methods.

The initial payment response may indicate that a transaction is still being processed. The final result may only become available later.

In these cases, your backend should use the notifications sent by Revup to detect subsequent status changes.

For example:

1. The customer submits the payment.
2. Revup returns in_process.
3. The customer completes the required payment flow.
4. The transaction is processed asynchronously.
5. Revup changes the transaction status to success.
6. Revup sends a notification.
7. Your backend updates the payment to success.

Notifications and token-based payments

Notifications also apply to token-based payments.

When a subsequent payment is created using a payment token, the resulting transaction can change state during its lifecycle.

Your backend should process the notifications for these transactions in the same way as notifications for an initial payment.

This is particularly important for merchant-initiated transactions, where there may not be an active customer checkout session when the transaction is processed.

Notifications and subscriptions

Notifications are also used for recurring payments generated by subscriptions.

When Revup creates a recurring payment according to the subscription plan, the resulting transaction can generate notifications as its status changes.

This allows your backend to keep the payment and subscription state synchronized without having to create or poll each recurring transaction manually.

For subscription-specific events and operations, see the Subscription API reference.

Notification reliability

Your notification endpoint should be designed to handle repeated or out-of-order notifications safely.

A transaction can generate multiple status changes, and your system should not assume that a single notification represents the complete lifecycle of the transaction.

When processing a notification:

• Identify the transaction using the transaction information provided by Revup.
• Store or update the transaction status in your system.
• Avoid creating duplicate business records when the same notification is received more than once.
• Do not assume that the first notification represents the final transaction state.

info

Notifications should be treated as transaction state updates rather than as one-time payment confirmations.

Your backend should maintain the current transaction state based on the information received from Revup.

Related documentation

• Handle the payment result — understand the different mechanisms used to determine the state of a payment.
• Refunds — manage refunds for applicable transactions.
• Chargebacks — handle chargeback events and related transaction updates.
• Subscription API reference — integrate and manage subscriptions.