Skip to main content

Refunds

A refund allows a merchant to return all or part of the amount charged to a customer.

Revup supports two ways to initiate a refund:

  • Revup Back Office — trigger the refund manually from the Back Office.
  • Revup API — request the refund directly from your integration.

Both methods support full and partial refunds.

Refund flow​

Full refunds​

A full refund returns the total amount originally charged to the customer.

For example, if a customer was charged €100, a full refund returns €100 to the customer.

A full refund can be initiated either from the Revup Back Office or through the Revup API.

Partial refunds​

A partial refund returns only part of the original transaction amount.

For example, if a customer was charged €100, the merchant can refund €25 while keeping the remaining €75 charged.

Partial refunds are useful when the merchant needs to return only part of an order or transaction amount.

Partial refunds can be initiated either from the Revup Back Office or through the Revup API.

info

The refund amount cannot exceed the amount available to be refunded from the original transaction.

Refund statuses​

A refund has one of three possible statuses:

StatusDescription
successThe refund has been successfully processed.
failedThe refund could not be processed successfully.
in_processThe refund is still being processed and has not reached a final state.

success​

The refund has been successfully processed.

The refunded amount has been returned through the payment processing flow.

This is a final refund status.

failed​

The refund could not be processed successfully.

This is a final refund status.

Your integration should handle the failed refund according to your business logic and determine whether another action is required.

in_process​

The refund is still being processed.

This is a non-final status.

A refund in in_process can take several days to reach a final state. The time required depends on the payment service provider (PSP).

Your integration should not treat an in_process refund as either successful or failed until a subsequent update provides the final status.

warning

Do not consider a refund completed solely because the refund request was accepted.

Always use the refund status to determine whether the refund has reached its final state.

Refunds from the Back Office​

A merchant can trigger a refund directly from the Revup Back Office.

This can be useful when a refund needs to be performed manually by an operator without making an API request from the merchant's application.

Back Office refunds can be either:

  • Full refunds.
  • Partial refunds.

When a refund is triggered from the Revup Back Office, Revup sends a notification to the merchant.

This notification is a not requested refund notification because the refund was not initiated through the merchant's API integration.

warning

Your backend should process not requested refund notifications.

A refund can also be initiated directly from the PSP Back Office, in which case Revup sends the corresponding notification to the merchant as well.

For more information about handling refund notifications, see Notifications.

Refunds through the API​

A merchant can also request a refund directly through the Revup API.

This allows the merchant's backend to initiate refunds programmatically as part of its own business logic.

For example, a merchant may initiate a refund after:

  • A customer requests a cancellation.
  • An order is partially cancelled.
  • An order is fully cancelled.
  • The merchant's system determines that a refund is required.

The API returns information about the refund, including its current status.

If the refund is in_process, your integration should wait for the corresponding status update rather than assuming that the refund has already been completed.

For the technical details of creating and managing refunds through the API, see the Refund API reference.

Refund notifications​

Refunds can generate notifications that allow your backend to keep its internal state synchronized with Revup.

This is particularly important when:

  • A refund was initiated from the Back Office.
  • A refund was initiated directly from the PSP Back Office.
  • An API-requested refund remains in_process and later reaches a final state.

Your notification endpoint should identify the refund and process its current status.

For more information about notification handling, see Notifications.

Refunds and transaction status​

A refund is a separate operation from the original payment transaction.

The original transaction may have reached a successful state before the merchant requests a refund.

The refund must therefore be tracked independently using its own refund status.

For example:

  1. The original transaction reaches success.
  2. The merchant requests a refund.
  3. The refund is created with status in_process.
  4. The PSP processes the refund.
  5. The refund changes to success.
  6. Revup sends the corresponding notification.
  7. The merchant updates its internal refund status.

This separation is particularly important when reconciling payments and refunds in the merchant's system.

Refunds for different payment flows​

Refunds can be associated with transactions created through the different Revup payment flows.

This includes:

  • One-off payments — refund the original payment when required.
  • Token-based payments — refund a specific subsequent transaction created using a payment token.
  • Subscriptions — refund an applicable recurring transaction.

The refund applies to the specific transaction being refunded. It does not automatically cancel a subscription or prevent future recurring payments.

info

Refunding a subscription payment does not by itself cancel the subscription.

If the merchant wants to stop future recurring payments, the subscription must be managed separately through the Subscription API.

When implementing refunds, your backend should:

  1. Store the refund request and associate it with the original transaction.
  2. Record the refund status returned by Revup.
  3. Treat success as the completed refund state.
  4. Treat failed as an unsuccessful refund.
  5. Keep in_process refunds pending until a final status is received.
  6. Process refund notifications to keep the refund status up to date.
  7. Handle not requested refund notifications so that refunds initiated from the Back Office or PSP are reflected in your system.
info

A refund request and a completed refund are not necessarily the same event.

A refund can remain in_process for several days depending on the PSP, so your system should support asynchronous refund status updates.