Transaction workflows

Transaction workflows

Please note that not all transaction types are supported for each payment method/acquirer. Make sure that the transactions and workflows you are planning to use are supported by the payment method and acquirer of your choice.

This guide serves only as a reference for all supported transactions and workflows. For details on each transaction type and/or operation, please refer to the respective detailed tutorials.

We can divide the transactions into three groups:

Initial transactions

These transactions can be the first in the workflow. They can be sent without referencing a previous transaction, but they all can be followed up by another transaction.

Registration/Tokenization (RG)


With tokenization the card data will be stored and can be re-used in later transactions.

How to use it:

Depending on your integration, there are multiple ways to create tokens. Follow the tokenization guide for more information.

Transactions that can follow a tokenization (RG) transaction:

Authorization (PA)


Authorize a transaction and reserve the amount on the cardholder's account. Additionally risk checks and 3D Secure can be performed during the authorization.

How to use it:

Include the parameter paymentType=PA in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow an authorization:

Debit (DB)


Debits the account of the end consumer and credits the merchant account. By sending a debit transaction, the funds are not only reserved, but immediately captured.

How to use it:

Include the parameter paymentType=DB in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow a debit:

Credit (CD)


Credits the account of the end consumer and debits the merchant account. Credit request transfers funds from Merchant's account to Shopper's account without referencing any previous purchase or transaction.

How to use it:

Include the parameter paymentType=CD in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow a credit:

Referencing transactions

These transactions cannot be the first one in the workflow. They will always reference a previous transaction either from the previous group, or another referencing transaction.

Capture (CP)


Captures a previously authorized (PA) amount. A successfully captured authorization will be sent to clearing and will move the funds from the shopper's account to the merchant's account. Can be full or partial.

How to use it:

Include the parameter paymentType=CP and the reference to the PA transaction in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow a capture:

Refund (RF)


Credits the account of the shopper with a reference to a prior debit (DB) or capture (CP) transaction. The shopper will see two transactions on their account statement: one for the purchase (DB or CP) and one for the refund. Can be full or partial.

How to use it:

Include the parameter paymentType=RF and the reference to the previous transaction in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow a refund:

Receipt (RC)


A receipt can be sent against a previous pre-authorization (PA) payment. Confirmation of the received funds after a pre-payment, invoice or bank transfer transaction.

How to use it:

Include the parameter paymentType=RC and the reference to the authorization in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow a receipt:

Rebill (RB)


Debits the account of the shopper with a reference to a prior Debit (DB) transaction. This is normally used to rebill an already processed Debit (DB) transaction in case of a chargeback or to add additional products to an already processed order.

How to use it:

Include the parameter paymentType=RB and the reference to a previous debit transaction in the request. For more information on how to send a request, please follow our tutorials.

Transactions that can follow a rebill:

Final transactions

These transactions will always terminate the workflow as no other transaction can follow them in a series of transactions.

Reversal (RV)


Voids payment authorization (PA). Since the amount is not cleared yet, there is no movement of funds and the shopper will simply won't see any booking on their account statement. For captured transactions (CP) or transactions where there is movement of funds (DB, CD) a reversal is not possible, instead a refund (RF) needs to be sent. Can be full or partial.

How to use it:

Include the parameter paymentType=RV and the reference to the authorization in the request. For more information on how to send a request, please follow our tutorials.

De-registration (DR)


Deletes a stored token.

How to use it:

Follow the tokenization guide

Standalone 3D Secure (3D)


Sends a standalone 3D Secure request independently of any payment. When sending a standalone 3D Secure transaction, it will always be the first and the last transaction in the flow.

How to use it:

Please follow our 3DS guide.