Skip to main content

PayIn API (v2)

PayIn v1 (POST /api/v1/payin) is deprecated. Existing integrations may continue to work, but all new development should use POST /api/v2/payin. See the v1 deprecated reference for legacy details and migration notes.
Use POST /api/v2/payin to create PayIn transactions. The response shape depends on the payment_method and the fields you send — not on a separate B2B/backoffice configuration.

Payment experiences

Timestamps are UTC. data.date and payment_information.expiration_date (when present) use YYYY-MM-DD HH:MM:SS in UTC. In Checkout mode, payment_information is not returned — only ticket, date, payment_url, and transaction.

Response structure

Checkout (hosted)

Direct (provider data only)

payment_url is omitted. Example: PSE with bank + person_type.

Hybrid (hosted + instructions)

Both payment_url and payment_information are returned. Example: EFECTY, BREB, BREB_QR, Peru QR, Mexico SPEI. Country-specific examples: This API enables customer deposit transactions across supported countries. Payment method availability is region-specific:
  • Colombia: ALL_METHODS, PSE, TRANSFIYA, EFECTY, CASH, CARD
  • Peru: BANK_TRANSFER, QR, CASH, CARD, PAGOEFECTIVO
  • Mexico: ALL_METHODS, CARD, CASH, SPEI, OXXO
  • Guatemala: ALL_METHODS, CARD, CASH, TRANSFER
  • Honduras: ALL_METHODS, CARD, CASH, TRANSFER
For comprehensive country-specific configuration (supported document types, currencies, banks, and payment methods), refer to the Colombia, Peru, Mexico, Guatemala, and Honduras documentation.

Transaction Limits

Amount limits:
  • Minimum amount (PSE): $2,000
  • Minimum amount (Efecty): $10,000
  • Maximum amount: $2,000,000
To adjust these limits, please contact the Tumipay support team at soporte@tumipay.co.

Transaction Flow

The PayIn process follows a clear sequence of interactions between different participants:

Card Payments (Colombia Only)

Card payment processing is currently available exclusively for Colombia (country: "CO"). Transactions follow the standard PayIn flow: initiate a transaction with payment_method set to CARD, redirect the customer to the payment_url, where they securely submit card details. The charge is processed asynchronously, and the final transaction status is delivered via webhook notification.

3D Secure

Some card transactions require 3D Secure (3DS) authentication. By having the 3DS authentication service active, your customers will be requested to complete an extra verification step (challenge) with the card issuer to finish the transaction. This challenge usually consists of an OTP sent by the bank to your customer’s e-mail address or telephone number. To test this flow in the sandbox environment, use the card numbers marked with Yes in the 3DS challenge column below. When the challenge screen appears, enter any six-digit code (for example 123456) to continue.

Sandbox test cards

Use the following card numbers in the sandbox environment. Use 123 as the CVV for all transactions:

Endpoints

POST Initiate a PayIn Transaction

/api/v2/payin

PayIn v2 — create transactions and receive checkout URLs, direct provider data, or both depending on the payment method.

/api/v1/payin (deprecated)

Legacy endpoint — returns only a hosted payment_url. Migrate to v2 for direct and hybrid flows.

Request Headers

string
required
Authentication token
string
required
Authorization key to access the resource

Request Body

string
required
A unique identifier sent by the client to track the transaction
integer
required
The total amount of the transaction
string
required
Three-letter currency code (ISO 4217). Use COP, PEN, MXN, GTQ, or HNL.
string
required
Two-letter country code (ISO 3166-1 alpha-2): CO, PE, MX, GT, or HN.
string
required
Specifies the payment method. See country-specific options:
string
Description of the transaction
string
required
The URL where the user will be redirected after completing the transaction
string
required
Webhook URL for transaction status updates
object
required

Response

string
required
Response code (see Error Codes)
string
required
Transaction status (e.g., “SUCCESS”)
string
Detailed message about the transaction status
object
required

Error Response

string
Error code (see Error Codes)
string
Error status (e.g., “ERROR”)
string
Type of validation error (e.g., “VALIDATION_ERROR”)
string
Details about the validation error

Examples for Peru

BANK_TRANSFER

The payment link will show the available banks for the transfer.

QR

A QR code is generated for the customer to scan and complete the payment.

PAGOEFECTIVO

Generates a cash voucher (PagoEfectivo) for the customer to pay at authorized locations or via online banking. The payment link will show the code and instructions.

Examples for Mexico

SPEI

The payment link opens a SPEI transfer form where the customer authorizes an interbank transfer.
Mexico SPEI uses Hybrid mode in v2: payment_information includes CLABE and expiration; payment_url is also returned. See Mexico PayIn.

OXXO

Generates a cash voucher the customer can present and pay at any OXXO convenience store.

CASH

Generates a cash payment reference for authorized collection points. customer_address is required for this method.

CARD (Mexico)

The payment link opens a secure card form for credit and debit card payments.

Error Codes

Examples by Payment Method

These examples use the same endpoint but change the payment_method field. The returned payment_url directs the customer to the appropriate interface for each method.

PSE — TumiPay checkout

Without bank / person_type: returns payment_url for hosted bank selection.

PSE — Direct

With customer_data.bank and customer_data.person_type: returns payment_information.payment_url (PSE redirect). List banks via GET /api/v1/pse/banks.

PSE — Checkout (hosted)

The payment link opens the bank selection screen on TumiPay checkout.

EFECTY

The payment link generates a cash voucher that must be presented at an Efecty location.

CARD

The payment link opens a secure card form. The webhook payload includes a top_card object with details of the card used.

Response Examples