Reference information

Technically, accepting a bank card for payment always comes down to debiting funds from the Customer's card. Throughout this documentation, this debit process is called a "payment". A payment can consist of a single operation or a sequence of operations.

Terms and definitions

Customer — a cardholder who makes a purchase in the Merchant's store.

Merchant — a legal entity or individual entrepreneur that sells goods or services online.

Acquiring bank — a bank that performs the initial processing of bank card transactions on behalf of a Merchant that is a client of this bank.

Issuing bank — the bank that issued the Customer's card.

Card scheme — an international payment system (Visa, Mastercard, etc.).

Terminal — a software component that enables automated payment acceptance. It has a set of settings that define the rules for processing payments.

Payment page — an HTML page the Customer uses to enter bank card payment details.

Transaction — the set of interactions between the bank cardholder and the payment processing center when an online card payment is made. A transaction changes the state of the card account. Each transaction has its own unique identifier.

Operation — a set of actions that results in a change of the transaction status and the state of the card account.

Examples: a charge; a hold on funds; a refund; a release of a hold.

One-step payment — a payment that consists of a single operation: a direct charge of funds from the Customer's card.

Two-step payment — a payment that involves two operations: holding funds on the card and completing the authorization, i.e. capturing (charging) the funds.

Hold (also "block", "authorization" or "pre-authorization" of funds) — a preliminary reservation of funds on the Customer's card.

Charge — the actual debiting of funds from the Customer's account.

In a two-step payment, the Merchant must initiate the capture within 7 days after a successful hold. If the charge is not initiated within this period, the operation may be disputed for violating card scheme rules. The issuer may also release the hold on the Customer's card automatically on its own. After that, completing the payment may no longer be possible.

Release of a hold (also "cancellation", "unblock" or "void of the authorization") — the reverse operation to a hold. Performed within a two-step payment.

Refund — the reverse operation to a charge. Performed after the charge in both one-step and two-step payments.

Recurring payment (also "autopay") — a Merchant-initiated payment with a previously added card, without re-entering the bank card details. To make recurring payments, the Customer's consent must be obtained during the first payment.

Examples: a monthly subscription fee charged by an online streaming service; automatic mobile phone top-up when the balance falls below RUB 100.

One-click payment (card-on-file) — a Customer-initiated payment with a previously added card, without re-entering the bank card details.

Example: ordering and paying for a taxi ride in an app with one click.

Chargeback — a procedure in which the Customer disputes a transaction: the payment amount is debited from the Merchant without its consent and returned to the Customer. After that, the burden of proving that the transaction is genuine falls on the Merchant.

3-D Secure (3DS) — a protocol used as an additional layer of security for online credit and debit card payments. The core idea of the protocol is to add online cardholder authentication to the financial authorization process.

Where the bank card data is entered

Payments differ not only in being one-step or two-step: the payment flow can also vary depending on how the payment card data is entered. In one integration option, the Customer enters their card details on a page of the Merchant's website; in the other, on a Payture web page.

On the Merchant's page

In this case, the Customer stays on the Merchant's website or in the Merchant's app throughout the payment and enters their payment card data there. The Merchant passes the entered data in the payment request.

Important! For security reasons, the major international card schemes require any party that handles payment card data to comply with the PCI DSS security standard. To confirm compliance with this standard, an organization (the Merchant) usually needs to complete a Self-Assessment Questionnaire (SAQ) of category D and have it verified, which may involve additional, though small, financial and organizational costs.

On the Payture side

With this option, the Merchant does not process payment data on its side and does not need to ensure data security on its own. Payment information is entered and the payment itself is made on the Payture payment gateway side:

• On the Payture payment page — in this case, the Customer stays on the Merchant's website only until they need to enter their payment card data, after which they are automatically redirected to a secure Payture page. After the payment, the Customer is informed of the result and returned to the Merchant's website, and the Merchant receives notifications with the payment results.
• Via the payment widget — a pop-up window embedded in the Merchant's website that appears when the "Pay" button is clicked. It includes secure input fields for payment data (the data is processed by Payture in accordance with security standards).

The appearance of the payment page or widget is determined by the template used. The standard Payture templates can be modified at the Merchant's request. The Merchant can use one or more different templates.