- Getting Started
- Tutorials
- Reference
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Response Parameters
- Card On File
- Chargeback
- Transaction Workflows
- Result Codes
- Brands Reference
- Regression Testing
- Data Retention Policy
- API Reference
- FAQ
Transaction workflows
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:
Chargeback (CB)
A negative booking on the merchant account which is generally triggered by the bank. It is a transaction forcibly initiated by issuer (on behalf of shopper) to return the funds to shopper’s bank account or credit card due to fraud, undelivered goods, etc.
How to use it:
Include the parameter paymentType=CB and the reference to a previous transaction in the request. For more information on how to send a chargeback request, please follow our tutorials.
Transactions that can follow a chargeback:
Chargeback Reversal (CR)
Reverses an already processed Chargeback (CB).
How to use it:
Include the parameter paymentType=CR and the reference to a previous chargeback in the request. For more information on how to send a request, please follow our tutorials.
Transactions that can follow a chargeback reversal:
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:
Schedule (SD)
With Scheduling API, you can schedule DB, PA or CD transaction in the future with already stored payment data.
How to use it:
Please follow our scheduling guide.
Transactions that can follow a scheduled transaction:
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.
Token extension (TE)
Each registered token has a retention period after which the token will be deleted. You can extend the retention period by up to 24 months for registration tokens.
How to use it:
Please follow our tokenization guide.
De-schedule (DS)
Cancels the schedule of future transactions.
How to use it:
Please follow our scheduling guide.
Standalone Risk (RE)
Sends a standalone fraud check request independently of any payment. When sending a standalone risk transaction, it will always be the first and the last transaction in the flow.
How to use it:
Please follow our fraud management 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.