Un pago es la operación principal: una venta, un reembolso, una preautorización o una finalización. Todos se realizan a través de un método — sendPaymentRequest — y se selecciona el tipo de pago con el campo paymentType. Esta guía cubre el pago regular; las variantes difieren solo en paymentType y se indican al final.
Requisito previo: una sesión activa. Consulte Ciclo de vida de la sesión y el inicio de sesión — sin un inicio de sesión exitoso, una solicitud de pago es ignorada.
La llamada
viewModelScope.launch {
clientSDK.sendPaymentRequest(
RetailerMessageArguments.PaymentRequestMessageArguments
.RegularPaymentRequestMessageArguments(
saleTransactionId = "Sale001",
paymentAmounts = PaymentAmounts(
currency = "EUR",
amount = BigDecimal("10.00")
),
paymentType = PaymentType.NORMAL
)
)
}
Los tres campos que necesitas:
-
saleTransactionId— tu referencia para la venta. Debe ser alfanumérico y de 35 caracteres o menos. Si lo obtienes de un UUID, elimina los guiones — un UUID sin formato tiene 36 caracteres y será rechazado. -
paymentAmounts— unPaymentAmounts. Como mínimo,currency(debe coincidir con la moneda configurada en el terminal) yamount(unBigDecimal). También puede incluirtipAmount,cashbackAmountypaidAmount— consulta la referencia de la API para la lista completa de campos. -
paymentType— unPaymentType.NORMALpara una venta estándar.
Leer el resultado
El resultado llega a tu interceptor como un subtipo de RetailerPaymentResponse:
when (message) {
is SuccessRetailerPaymentResponse -> { /* aprobado — leer datos del POI, montos */ }
is ErrorRetailerPaymentResponse -> { /* rechazado o fallido */ }
is PartialRetailerPaymentResponse -> { /* resultado parcial — manejar explícitamente */ }
is RetailerDisplayRequest -> { /* actualización de progreso durante el procesamiento */ }
}
Maneja los resultados del supertipo, no solo el éxito — consulta Cómo funciona el modelo de mensajes para entender por qué. Los mensajes RetailerDisplayRequest llegan durante el procesamiento para informar qué está haciendo el terminal; no son el resultado final.
El
POITransactionIDes importante más adelante. Una respuesta de pago exitosa lleva unPOITransactionIDen sus datos del POI. Si puede que necesites revertir este pago, captura ese ID ahora — la reversión lo necesita. Consulta Guía: revertir una transacción.
Las variantes de pago
No llamas a un método diferente para reembolsos o preautorizaciones — cambias el paymentType. Se aplican los mismos tipos de solicitud y respuesta; no existen subtipos de respuesta separados para reembolso o preautorización. Un RetailerDisplayRequest durante el procesamiento indica qué operación se está ejecutando.
| Quieres… |
Establecer paymentType a
|
|---|---|
| Realizar una venta estándar | PaymentType.NORMAL |
| Reembolsar a un cliente | PaymentType.REFUND |
| Preautorizar (reservar un monto) | PaymentType.FIRSTRESERVATION |
| Completar una preautorización previa | PaymentType.COMPLETION |
PaymentType define 13 valores en total (incluyendo pago a plazos, recurrente, adelanto en efectivo y otros). Los cuatro anteriores son los más comunes; el enum completo está en la referencia de la API. Usa la constante exacta del enum — los valores están en mayúsculas (NORMAL, no Normal).
Abortar un pago en curso
Un pago que ha comenzado pero aún no ha alcanzado la autorización del host puede cancelarse con sendAbortRequest(). Después de la autorización es demasiado tarde para abortar — usa una reversión en su lugar. Consulta Guía: revertir una transacción y Solución de problemas: abortar no tiene efecto después de la autorización.
Relacionado
- Inicio rápido — la guía para el primer pago.
- Cómo funciona el modelo de mensajes — manejar la respuesta correctamente.
- Guía: revertir una transacción — deshacer un pago completado.
- Guía: adquisición de tarjeta y pagos en dos pasos — lectura previa de la tarjeta y luego completar.
-
Referencia de la API (
sdk-doc.zip) — campos completos dePaymentAmountsy el enum completoPaymentType.