Process payments
To continue with the integration, you must integrate payment processing through the Orders API. This will allow you to receive frictionless payments initiated by the customer (CIT) or payments initiated by the merchant (MIT) without the need to re-enter data.
With Automatic Payments, it is possible to process two types of payments based on their recurrence:
- Scheduled recurring payments: these are payments that have a pre-established periodicity, such as subscriptions, recurring payments, or renewals.
- One-time payments with saved cards (Card on File): these are one-time payments that do not require re-entering card data, but rather reuse the previously registered payment method to process transactions. These can be CIT, in the case of one-click payments or repurchases, or MIT, in the case of consumption debits.
flowchart TD
A[Process payment] --> B{Is it a scheduled payment?}
%% Recurring payments
B -- Yes --> C[Scheduled recurring payment]
C --> C1{Is it the first payment in the chain?}
C1 -- Yes --> RCIT[CIT
Customer Initiated Transaction]
C1 -- No --> RMIT[MIT
Merchant Initiated Transaction]
%% UCOF payments
B -- No --> U[Saved card payment
UCOF]
U --> P{Is the user present?}
P -- Yes --> UCIT[CIT
Customer Initiated Transaction]
P -- No --> UMIT[MIT
Merchant Initiated Transaction]
%% Examples
RCIT --> RCIT1[Subscription signup / First recurring payment]
RMIT --> RMIT1[Subsequent payments in the chain / Automatic renewals]
UCIT --> UCIT1[One-click / Repurchase]
UMIT --> UMIT1[Consumption debits]
Additionally, the Orders API allows you to choose the mode in which Automatic Payments can be processed.
Orders processing modes
An Automatic Payments order can be created to be processed in two main modes: Synchronous mode and Asynchronous mode.
The processing mode definition is made when creating the order, through the processing_mode parameter. Its value should be automatic for synchronous processing, or automatic_async to process the order asynchronously.
Synchronous mode allows the transaction to be completed in a single step. Through this mode, the payment is processed immediately and the response is received in real time.
To create the order in synchronous mode, the processing_mode field, which is responsible for defining the transaction creation and processing format, must be set to automatic.
The allowed operations are:
- Create and process orderAPI: responsible for creating the order and processing the transaction simultaneously.
- Get orderAPI: allows you to get information about an order, including its real-time status.
- Cancel orderAPI: responsible for canceling an existing order that has not yet been processed.
- Refund orderAPI: allows total or partial refund of a payment made with a credit card. The order will be fully refunded if all transactions are completely refunded.
- Full refund: no amount to refund should be indicated in the request body, which should be empty.
- Partial refund: the amount to refund must be specified in the request body, along with the transaction ID. All other transactions will remain as they are and only the modified transaction will be refunded.
Rules for Automatic Payments in synchronous mode
- Only allows processing payments with cards (credit, debit, or prepaid).
- Processing payment intents with profiles containing more than one card is not allowed. In these cases, the system prevents synchronous payment and returns the
invalid_payment_methodserror. - For this same reason, synchronous mode only allows retry logic with a single payment method, which can be defined through the
max_day_overduefield in the customer's payment profile creation.
