Tabla pedagógica: los 28 casos de comienzo a fin¶
No necesitas conocer términos de pagos. Busca una necesidad y lee su fila de izquierda a derecha. Cada columna es una pregunta concreta que una integración real debe responder.
1 Necesidad→2 Inicio→3 Proceso→4 Confirmación→5 Cierre
Ejemplo en 30 segundos
Una compra de $19.990 con Webpay
- Inicio: tu backend crea una orden y una referencia.
- Proceso: Transbank presenta la pantalla y procesa la tarjeta.
- Confirmar: tu backend ejecuta
commit; volver al navegador no basta. - Cerrar: el ledger registra una sola operación y después se concilia con el reporte.
- Si hay timeout: queda
UNKNOWNy se consulta; no se cobra otra vez a ciegas.
Aquí comienza la tabla: 28 casos¶
Escribe una palabra para reducir las filas. Por ejemplo: presencial, recurrente, Chile, banco o agente.
Mostrando 28 de 28 casos.
| # | Caso | ¿Para qué sirve? | 1 · Inicio | 2 · Proceso | 3 · Confirmar | 4 · Cerrar | Si falla | Para hacerlo real |
|---|---|---|---|---|---|---|---|---|
| 01 | Efectivo y cajafuente MD · PDF | Cobro presencial sin red electrónica. | Cajero abre turno y registra monto. | Recibe efectivo y emite recibo único. | Cuenta caja con segundo responsable. | Deposita y concilia recibos contra banco. | Faltante/sobrante queda como excepción; nunca se borra. | Caja web + roles + impresora + PostgreSQL + archivo bancario. |
| 02 | Cheques y órdenes en papelfuente MD · PDF | Cheque u orden física con cobro diferido. | Registra emisor, monto, fecha e imagen restringida. | Entrega el documento al banco y queda PENDING. | El banco informa cobro o devolución. | Aplica asiento final y concilia cartola. | Cheque devuelto revierte disponibilidad y abre cobranza. | Backoffice + custodia + API/archivo bancario + reglas locales. |
| 03 | Tarjetasfuente MD · PDF | Pago inmediato con tarjeta física o digital. | Backend crea order/payment intent. | PSP tokeniza, autentica y autoriza; luego captura. | Webhook o consulta confirma la captura. | Adquirente liquida; comercio concilia fees y disputas. | Timeout queda UNKNOWN; chargeback se registra por separado. | Checkout alojado + REST API + webhook + PostgreSQL + PCI DSS. |
| 04 | Transbank Webpay Plusfuente MD · PDF | Tarjetas en Chile mediante checkout alojado. | Backend crea transacción Webpay y guarda token. | Cliente paga en Transbank y vuelve al comercio. | Backend ejecuta commit una sola vez; status recupera timeout. | Reporte Transbank se concilia con ledger y banco. | Retorno sin commit no prueba pago; UNKNOWN se consulta. | Contrato Transbank + REST Webpay + callback + credenciales separadas. |
| 05 | Transbank Oneclick Mallfuente MD · PDF | Cobros posteriores a una tarjeta previamente inscrita. | Start/finish inscribe y entrega tbk_user. | Backend autoriza por tienda usando token protegido. | Status confirma; webhook/consulta actualiza la orden. | Conciliar autorizaciones, refunds y liquidación por tienda. | Baja o rechazo no permite reutilizar una inscripción inválida. | Contrato Oneclick + REST + vault cifrado + consentimiento y límites. |
| 06 | Khipufuente MD · PDF | Transferencia cuenta a cuenta iniciada desde el comercio. | Backend crea pago Khipu con referencia y callbacks. | Cliente autoriza en su experiencia bancaria. | Webhook autenticado o consulta confirma el payment ID. | Abono bancario se concilia contra la misma referencia. | Callback perdido se recupera consultando; nunca por captura de pantalla. | Cuenta cobrador + Payment API + webhook HTTPS + llave en secret manager. |
| 07 | Mercado Pagofuente MD · PDF | Checkout regional con tarjetas y otros medios. | Frontend tokeniza o redirige; backend crea orden. | Payments/Orders API procesa con idempotency key. | Webhook validado y consulta fijan el estado. | Reporte y disponibilidad del dinero se concilian. | Evento duplicado se reconoce sin repetir ledger ni entrega. | Cuenta vendedor + app test + SDK frontend + REST backend + webhooks. |
| 08 | POS, mPOS y SoftPOSfuente MD · PDF | Cobro presencial en POS, mPOS o SoftPOS. | Caja envía monto y referencia al terminal. | Dispositivo certificado lee y autentica la tarjeta. | Terminal/adquirente devuelve autorización y voucher. | Cierre de lote se concilia con caja y banco. | Desconexión exige consulta/reversa; no repetir venta a ciegas. | Terminal certificado + SDK/protocolo de caja + gestión de dispositivos. |
| 09 | Wallets tokenizadasfuente MD · PDF | Apple Pay, Google Pay u otra wallet tokenizada. | Usuario elige wallet en dominio/app registrado. | Wallet crea token de red y criptograma. | Backend/PSP valida token y confirma autorización. | Liquidación y disputa siguen el rail de tarjeta. | Token inválido expira; fallback no debe exponer PAN. | SDK wallet + validación de dominio + PSP + gestión de claves. |
| 10 | Saldo almacenado y gift cardsfuente MD · PDF | Gift card o saldo mantenido por el propio programa. | Identifica cuenta y saldo disponible. | Reserva atómica evita gastar dos veces. | Captura consume saldo o libera la reserva. | Ledger demuestra saldo y pasivo del programa. | Carrera o timeout se resuelve por idempotencia y reserva expirable. | API propia + PostgreSQL transaccional + ledger + reglas regulatorias. |
| 11 | Mobile moneyfuente MD · PDF | Pago desde saldo móvil con red de agentes. | Identifica wallet, cliente y agente. | Operador valida PIN/OTP y mueve saldo. | Referencia del operador confirma el pago. | Saldos, comisiones y float de agentes se concilian. | Falta de liquidez o reversa abre una excepción trazable. | Contrato operador + API/USSD + KYC + gestión de agentes y float. |
| 12 | Pagos QRfuente MD · PDF | Iniciar un pago escaneando un código. | Genera QR firmado, único y expirable. | App interpreta datos e inicia el rail subyacente. | API/webhook del rail confirma; el QR no confirma. | Conciliar referencia QR contra abono o adquirente. | QR sustituido/expirado se rechaza; duplicado no reaplica. | Estándar QR + firma + backend + proveedor bancario o wallet. |
| 13 | Transferencia bancariafuente MD · PDF | Pago directo entre cuentas bancarias. | Entrega beneficiario y referencia irrepetible. | Cliente o API bancaria instruye transferencia. | Cartola/API autoritativa confirma el abono. | Concilia monto, moneda, referencia y fecha valor. | Comprobante visual se ignora; diferencia queda pendiente. | Cuenta empresa + API/open banking o archivos + conciliador. |
| 14 | ACH y transferencias batchfuente MD · PDF | Transferencias masivas diferidas por lote. | Crea lote válido, totales de control y fecha. | Operador acepta archivo y procesa entries. | Acuse y settlement reportan cada entry. | Returns posteriores ajustan ledger y conciliación. | Lote rechazado se corrige completo; return no se oculta. | Acuerdo ODFI/operador + formato NACHA/local + SFTP/API + scheduler. |
| 15 | Débito directofuente MD · PDF | Cobros recurrentes autorizados desde cuenta. | Captura mandato, versión y consentimiento. | Presenta débito en la fecha notificada. | Banco informa aceptación o return. | Liquida y concilia por mandato/referencia. | Revocación o fondo insuficiente detiene nuevos intentos según regla. | Proveedor DD + vault de mandatos + batch/API + calendario y avisos. |
| 16 | Pagos instantáneosfuente MD · PDF | Transferencia cuenta a cuenta casi inmediata 24/7. | Resuelve alias/cuenta y crea referencia end-to-end. | Rail valida e instruye en tiempo real. | Confirmación con finalidad declarada cierra el pago. | Concilia mensajes, cuentas técnicas y banco. | UNKNOWN exige status; rapidez no autoriza duplicar. | Participante/proveedor + API ISO 20022/local + operación 24/7. |
| 17 | Links y solicitud de pagofuente MD · PDF | Cobrar mediante link o solicitud compartible. | Crea orden firmada, expirable y de un solo uso. | Cliente abre link y elige el rail final. | Backend confirma por API/webhook del rail. | Atribuye liquidación a orden, campaña o factura. | Link reutilizado o phishing se bloquea por firma/dominio. | Frontend de checkout + URL firmada + PSP + antifraude. |
| 18 | Voucher pagable en efectivofuente MD · PDF | Orden digital pagada posteriormente en una red física. | Genera barcode/referencia y vencimiento. | Recaudador recibe efectivo y reporta la operación. | Archivo/API de la red confirma una sola vez. | Settlement del recaudador se concilia con voucher. | Voucher vencido/duplicado se rechaza o queda en excepción. | Contrato recaudador + barcode + API/archivo + conciliación diferida. |
| 19 | BNPL y crédito alternativofuente MD · PDF | Compra financiada en cuotas por un tercero. | Solicita evaluación y muestra costo total. | Cliente consiente; financiador aprueba y paga comercio. | API confirma contrato y desembolso. | Comercio concilia neto; financiador administra cuotas. | Rechazo, mora o devolución siguen flujos separados. | Proveedor BNPL + API/SDK + consentimiento + regulación de crédito. |
| 20 | Cobro mediante operador móvilfuente MD · PDF | Cargo a factura o saldo del operador móvil. | Verifica línea, elegibilidad y límite. | Usuario confirma con OTP/consentimiento. | Operador devuelve transaction ID. | Reporte divide ingreso entre comercio y operador. | Suscripción o cargo discutido se revierte con evidencia. | Contrato carrier/agregador + API + OTP + gestión de suscripciones. |
| 21 | Marketplaces, splits y payoutsfuente MD · PDF | Marketplace que cobra y paga a terceros. | Onboarding/KYB habilita cada beneficiario. | Cobro crea split inmutable, comisión y reserva. | Webhook confirma entrada y subledger distribuye. | Payout liquida a vendedores y se concilia. | Refund/chargeback reasigna saldos sin perder el bruto original. | PSP marketplace + cuentas conectadas + subledger + motor de payouts. |
| 22 | Pagos B2B y tesoreríafuente MD · PDF | Pago de facturas con aprobaciones empresariales. | Ingiere factura y valida proveedor. | Segregación de funciones aprueba instrucción. | Banco confirma ejecución y remittance. | ERP, banco y factura se concilian. | Duplicado/cambio de cuenta bloquea pago y escala revisión. | ERP + workflow de aprobación + API bancaria/SFTP + sanciones. |
| 23 | Pagos internacionalesfuente MD · PDF | Pago entre países con FX y corresponsales. | Cotiza tasa, fees, beneficiario y vigencia. | Screening y red corresponsal procesan instrucción. | Tracking confirma estado y monto recibido. | Fecha valor, FX y fees se concilian. | Sanción, repair o devolución mantiene trazabilidad del original. | Proveedor cross-border + KYC/AML + FX + SWIFT/ISO 20022. |
| 24 | RTGS y alto valorfuente MD · PDF | Transferencia urgente de alto valor por RTGS. | Operador autorizado crea instrucción. | Segundo aprobador firma; rail gestiona cola/liquidez. | Mensaje de finalidad confirma irrevocabilidad. | Tesorería concilia intradía y posición de liquidez. | Rechazo/cola no se marca pagado; escala a operación crítica. | Acceso institucional + PKI/HSM + doble control + monitoreo RTGS. |
| 25 | Open Finance e iniciaciónfuente MD · PDF | Iniciar pago desde una app con consentimiento bancario. | TPP crea consentimiento con alcance y expiración. | Cliente autentica en banco; FAPI entrega token ligado. | Payment ID se consulta hasta estado final. | Banco y comercio concilian referencia end-to-end. | Consentimiento revocado/token vencido exige nueva autorización. | Registro/licencia TPP + OAuth/OIDC FAPI + mTLS + API bancaria. |
| 26 | Bitcoin, Lightning y activos digitalesfuente MD · PDF | Transferir Bitcoin, Lightning u otro activo. | Genera address/invoice y política de expiración. | Wallet firma y red propaga o enruta. | Confirmaciones o payment hash prueban resultado. | Custodia, fees y conversión fiat se concilian. | Reorg, fee insuficiente o pérdida de clave usa runbook específico. | Nodo/custodio + wallet segura + indexador + compliance y recovery. |
| 27 | Pagos máquina a máquinafuente MD · PDF | Dispositivo paga automáticamente por uso. | Identidad del equipo recibe presupuesto y política. | Medición genera autorización de alcance mínimo. | Servicio confirma consumo y cargo firmado. | Agrega micropagos y concilia por dispositivo. | Equipo comprometido se revoca; límite evita gasto ilimitado. | Identidad de dispositivo + attestation + API + wallet/rail + límites. |
| 28 | Pagos realizados por agentesfuente MD · PDF | Un agente de software compra bajo mandato. | Humano define propósito, presupuesto y expiración. | Motor de políticas decide y pide aprobación si corresponde. | Backend ejecuta y guarda evidencia de mandato/resultado. | Ledger y conciliación atribuyen gasto al responsable. | Ambigüedad o exceso de límite detiene, no improvisa. | Agent API + policy engine + aprobación humana + credencial limitada. |
Qué debes poder explicar después de elegir una fila¶
- Quién crea la referencia: normalmente tu backend.
- Quién tiene autoridad para confirmar: API, webhook, banco, operador o archivo; nunca una captura.
- Qué pasa si no sabes el resultado: conservar
UNKNOWN, consultar y evitar un segundo efecto. - Cómo pruebas el dinero: ledger balanceado y conciliación contra la fuente externa.
- Qué falta para LIVE: contrato, credenciales separadas, seguridad, operación y regulación.
Después abre el laboratorio en localhost para ejecutar cuatro fallos, o el casebook detallado para revisar cada modalidad.
La arquitectura común¶
flowchart LR
U[Persona o sistema] --> F[Frontend o canal]
F --> B[Backend: orden e idempotencia]
B --> P[Proveedor o rail]
P --> C[API, webhook o archivo]
C --> L[Ledger]
L --> R[Conciliación y operación]
En una frase: la tecnología cambia por fila; las responsabilidades no. El backend decide, una fuente autoritativa confirma y la conciliación demuestra.