Skip to main content
Un payment intent representa una petición de cobro concreta: un monto, los activos que el pagador puede usar, metadata opcional, y las direcciones a las que enviar fondos. Creado vía POST /payment-intents, leído vía GET /payment-intents/{id}, listado vía GET /payment-intents. El mismo envelope lo devuelven los tres endpoints + el simulador sandbox + cualquier evento del log relacionado al intent. Construye tu cliente alrededor de este envelope y tienes un solo decoder para cada entry point.

El envelope

Todo campo abajo está siempre presente en la respuesta, con null cuando no aplica. Es deliberado — código del partner que hace response.metadata sin guard no se rompe en intents sin metadata. Estilo Stripe.

Transiciones de estado

failed está reservado para uso futuro; ningún path actual lo emite. Construye tu cliente para ignorar estados futuros desconocidos sin romper.

Campos cumulativos

Los tres campos cumulativos cierran el gap del pago parcial: un depósito de 3contraunintentde3 contra un intent de 5 es estructuralmente distinto de “todavía no llegó nada”. Usa partial_payment como el boolean de dispatch — respeta transitivamente la tolerancia de 0.01 que usa el backend para decidir completion. Un intent dentro de tolerancia ya pasó a completed, así que partial_payment es false y el booleano te dice renderiza éxito, no parcial.

Ciclo de pago parcial

Ejemplo concreto: intent de 5,pagadorenvıˊa5, pagador envía 3 y luego $2.
Dos cosas para anotar:
  1. deposit es el ÚLTIMO crédito, no el acumulado. En el flujo parcial→completo, deposit.amount_received muestra los 2(eluˊltimo).Elamountreceivedtoplevelmuestraelacumulado2 (el último). El `amount_received` top-level muestra el acumulado 5. No sumes deposit.amount_received entre polls — usa el campo top-level.
  2. La tolerancia es invisible para ti. Un depósito de 4.995contraunintentde4.995 contra un intent de 5.00 pasa el status a completed (dentro de la tolerancia de 0.01 que usa el flujo de crédito). partial_payment es false. Confía en el booleano; no reimplementes el threshold del lado del cliente.

Polling

Un widget poleando GET /payment-intents/{id} para estado debe despachar en un árbol de decisión pequeño:
El SDK del navegador hace esto por ti — ver mountPaymentWidget y normalizeIntent.

El objeto deposit

deposit se puebla cuando un crédito aterriza. En el flujo parcial→completo refleja el ÚLTIMO crédito en cada lectura (no el acumulado). Usa amount_received (top-level) para acumulado.
Este objeto es idéntico campo-por-campo al shape data del evento webhook payment_intent.completed. Partners que hacen reconciliación pull (GET) y push (webhook) pueden usar un solo decoder para los dos.

Transacciones atribuidas a Connect

Cada fila que devuelve GET /transactions carga un campo payment_intent_id. Si es no-null, esa transacción fue un crédito contra el intent nombrado (flujo SDK-driven). Si es null, la transacción vino por otro path (depósito directo a dirección org-owned, transferencia, funding interno). Úsalo para deep-linkear filas de transacción a su intent originador en los dashboards del partner.

Ver también