Skip to main content
If you still call POST /api/v1/payin, that endpoint is deprecated. Use POST /api/v2/payin for all new integrations.

Overview

The PayIn API for Peru enables customer deposit transactions through multiple payment methods including bank transfers, QR code payments, and PagoEfectivo cash vouchers. Transactions are processed in real-time with webhook notifications for status updates.

Key Features

  • Multiple Payment Methods: BANK_TRANSFER, QR, PAGOEFECTIVO
  • Currency: Peruvian Sol (PEN)
  • Real-time Processing: Immediate transaction validation and processing
  • Webhook Notifications: Asynchronous status updates via IPN
  • Secure Redirect Flow: Customer completes payment on secure hosted page

Quick Reference


Payment experiences (v2)

QR returns payment instructions in payment_information at creation time and also provides payment_url as a hosted fallback. Maximum amount: 500 PEN. All dates are UTC (Y-m-d H:i:s).

Response fields by method

QR β€” Hybrid

QR amount limits

If amount is greater than 500 PEN, the API responds with HTTP 422 and does not create a transaction:
Amounts above 500 PEN are rejected at validation time. Adjust amount before calling POST /api/v2/payin with payment_method: "QR".

BANK_TRANSFER / CASH β€” Checkout

Mode: Checkout Β· You get: payment_url only (no payment_information). Send the method without extra fields. Redirect the customer to data.payment_url.

Required Fields

Customer Data Object

Optional Fields


QR Code Direct Flow (deprecated)

This flow applied to PayIn v1 (POST /api/v1/payin) with the ExperienciaQrCode flag enabled in TumiPay backoffice configuration. It is deprecated β€” use QR Hybrid (v2) with POST /api/v2/payin instead. Contact integrations if you still rely on the v1 flag.
Unlike the standard checkout flow (which returned a payment_url to redirect the customer), the v1 QR direct flow generated the QR code at transaction creation and returned it as a base64 image in the response. The merchant was responsible for rendering and displaying it.

v1 vs v2 response shape

How it worked (v1)

QR amount limits (v1)

Request example (v1 β€” QR direct)

The request was identical to the standard flow; the only change was payment_method: "QR":

Response example (v1 β€” QR direct)

The response included all standard fields plus qr_code_base_64 directly inside data (not in payment_information):

Render the QR (v1)

In v2, read the QR from data.payment_information.qr_code_base_64 instead β€” see Payment experiences (v2).

QR-specific errors (v1)

When the customer completed payment, TumiPay sent a webhook to ipn_url. See Webhooks for the payload structure.

Response Structure

Success Response

Data Object


Examples

Request Example

cURL

Response Example