Please try searching something.
Payment Scenarios
One-step
Description
For one-step transactions, the sum paid for the purchase is written off the customer's account immediately.
Request Example
Two-step
Description
For two-step transactions, money is not immediately written off the customer's account: it is reserved on the card and captured later. Capture can be made only once; namely, if it is not made in full, the rest of the amount will be returned.
Request Example
AUTH
Description
Authorization-only transactions allow merchants to save the payment method and reserve funds for subsequent payments in the future. Namely, AUTH scenario allows registering a recurring without executing a financial transaction.
Request Example
Recurring
Overview
Recurring is merchant initiated transactions for automatic or systematically repeated payments, using previously saved customers' card data.
In order to use Recurring, at first, the card data has to be saved: learn more about it in the Payment Method Saving section. Card data can be saved either on the merchant's side or on the DECTA side.
Two types of Recurring are supported:
- Automatic (Merchant Initiated Transactions (MIT); unscheduled): off-session payments for which the cardholder does not participate and for which the merchant charges their customers irregularly and for different amounts. For example, taxi apps - the cardholder is charged for the final amount at the end of the ride, and the charging does not require cardholder’s confirmation;
- Recurring (Merchant Initiated Transactions (MIT); scheduled): off-session payments for which the cardholder does not participate and for which the merchant charges their customers regularly for the same amount. For example, gym memberships - the cardholder is charged at the beginning or the end of the billing cycle and it is always done for the same amount.
Recurring is compatible with the following payment scenarios:
- One-step
- Two-step
- AUTH
- MOTO
Request Example
One-click
Overview
One-click (Cardholder Initiated Transactions (CIT)) payments are on-sessions payments where the cardholder participates. Example, food delivery apps where the cardholder creates a cart and approves the final amount for authorization at the end.
In order to use One-click, at first, the card data has to be saved: learn more about it in the Payment Method Saving section. Card data can be saved either on the merchant's side or on the DECTA side.
One-click is compatible with the following payment scenarios:
- One-step
- Two-step
- AUTH
- MOTO
Request Example
Full Refunds
Overview
Full Refunds allow you to return cash funds in full amount to the customer’s card account.
Request Example
Partial Refunds
Overview
Partial Refunds allow you to return cash funds in a partial amount to the customer’s card account.
Request Example
Reversals
Overview
Reversal transactions can be only carried out on the same day the customer has paid the order. Reversal allows you to return money only in full.
Request Example
Payouts: A2A
Overview
A2A (Account to Account) is a money transfer between the accounts of one individual.
Request Example
Payouts: B2P
Overview
B2P (Business to Person) is a money transfer made from a business institution to an individual. Use cases include insurance claims, healthcare reimbursements, legal settlements, loan disbursements, etc.
Request Example
Payouts: P2P
Overview
P2P (Peer to Peer) transaction is a money transfer made from one individual to another through an intermediary, typically referred to as a P2P payment application.
Request Example
Payouts: OG
Overview
OG payouts are a solution for online gaming transactions.
Request Example
Payouts: SDWO
Overview
SDWO (Staged Digital Wallet Operator) payouts are transactions made from the cardholder's digital wallet to their card account.
SDWO transactions are available only for the IPSP partners.
Request Example
Additional Capabilities
Payment Method Saving
Overview
Payment Method Saving is the first payment of a newly created payment series, during which the payment method is saved and the subsequent payment scenario is assigned to it.
Request Example
Use of Travel Data
Overview
Travel Data is a service that allows merchants and travel agencies to add relevant travel information to financial transactions; namely, information about airline addendum, lodging, car rentals, cruises, and ground transportation.
Use of Travel Data is compatible with the following payment scenarios:
- One-step
- Two-step
- Recurring
- Payment Method Saving
- MOTO
Request Example
Use of Account Funding details
Overview
Account Funding provides the option for one individual (merchant's client) to fund another individual's (also merchant's client) account. Account Funding is compatible only with One-step payments.
Request Example
Use of Dynamic Descriptor
Overview
Dynamic Descriptor provides a detailed description of transactions to help your customers recall their buying experience and avoid any disputes. In most cases, well-designed and informative dynamic descriptors eliminate any ambiguities or concerns about bank statements, as well as reduce chargebacks and identity fraud-related risks.
Request Example
QCash
Overview
QCash transactions are payments made in One-step and Two-step payment mode for cryptocurrency merchants.
Request Example
MOTO
Overview
If your business receives orders via the Internet, you can still process card transactions by using the Mail Order/Telephone Order (MOTO) feature. MOTO allows you to process transactions without the cardholder and their card being present in your place of business (transactions without CVV).
MOTO is compatible with the following payment scenarios:
- One-step
- Two-step
- AUTH
Request Example
SDWO Funding Payments
Overview
SDWO (Staged Digital Wallet Operator) Funding Payments are transactions made from the cardholder’s card to their digital wallet.
Request Example
SDWO Purchase Payments
Overview
SDWO (Staged Digital Wallet Operator) Purchase Payments are transactions made from the cardholder’s card to the merchant’s wallet for a specific purchase.
Request Example
Jump to
- One-step
- Two-step
- AUTH
- Recurring
- One-click
- Full Refunds
- Partial Refunds
- Reversals
- Payouts: A2A
- Payouts: B2P
- Payouts: P2P
- Payouts: OG
- Payouts: SDWO
- Additional Capabilities
- Payment Method Saving
- Use of Travel Data
- Use of Account Funding details
- Use of Dynamic Descriptor
- QCash
- MOTO
- SDWO Funding Payments
- SDWO Purchase Payments