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