# MD for: https://www.mercadopago.com.mx/developers/es/docs/automatic-payments-orders/process-payments.md

\# 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\](https://www.mercadopago.com.mx/developers/en/docs/automatic-payments-orders/process-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)\](https://www.mercadopago.com.mx/developers/en/docs/automatic-payments-orders/process-one-time-payments):\*\* 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. ::::TabsComponent :::TabComponent{title="Synchronous mode"} \*\*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: \* :TagComponent{tag="API" text="Create and process order" href="/developers/en/reference/online-payments/checkout-api/create-order/post"}: responsible for creating the order and processing the transaction simultaneously. \* :TagComponent{tag="API" text="Get order" href="/developers/en/reference/online-payments/checkout-api/get-order/get"}: allows you to get information about an order, including its real-time status. \* :TagComponent{tag="API" text="Cancel order" href="/developers/en/reference/online-payments/checkout-api/cancel-order/post"}: responsible for canceling an existing order that has not yet been processed. \* :TagComponent{tag="API" text="Refund order" href="/developers/en/reference/online-payments/checkout-api/refund-order/post"}: 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\_methods\` error. - For this same reason, synchronous mode \*\*only allows retry logic with a single payment method\*\*, which can be defined through the \`max\_day\_overdue\` field in the customer's \[payment profile creation\](https://www.mercadopago.com.mx/developers/en/reference/automatic-payments/payment-profiles/post). ::: :::TabComponent{title="Asynchronous mode"} \*\*Asynchronous mode\*\* allows the use of multiple payment methods and automatic retries. This mode is ideal for recurring payment scenarios where greater flexibility is required. To create the order in asynchronous mode, you need to ensure that the \`processing\_mode\` field, responsible for defining the transaction creation and processing format, is set to \`automatic\_async\`. The allowed operations are: \* :TagComponent{tag="API" text="Create and process order" href="/developers/en/reference/online-payments/checkout-api/create-order/post"}: responsible for creating the order and processing the transaction simultaneously. \* :TagComponent{tag="API" text="Get order" href="/developers/en/reference/online-payments/checkout-api/get-order/get"}: allows you to get information about an order, including its real-time status. \* :TagComponent{tag="API" text="Cancel order" href="/developers/en/reference/online-payments/checkout-api/cancel-order/post"}: responsible for canceling an existing order that has not yet been processed/completed. \* :TagComponent{tag="API" text="Refund order or transaction" href="/developers/en/reference/online-payments/checkout-api/refund-order/post"}: in manual mode, you can create total or partial refunds 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 will 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 asynchronous mode Asynchronous mode is the one that allows \*\*retry logic\*\* configured within the Orders API structure and not only the one configured in the Profiles API. This logic works as follows: - When creating the order, you can configure retry logic through the \`retries\` field, which allows you to set how many retries will be made to process the payment in case of an initial failure. > NOTE > > > If the Profile has the \`max\_day\_overdue\` field configured, it will take priority over the \`retries\` field sent in the Order. - When this initial processing fails, and if the payment profile used has multiple registered payment methods, the system will retry the payment using each of them until it is successful or canceled. - If all payment methods fail, the transaction and order status will be \`failed\`. ::: ::::