Aceptar un pago

El flujo

1. El cliente hace clic en pagar; usted abre el checkout.
2. El SDK crea el pago y muestra las cadenas y los tokens disponibles.
3. El cliente conecta una wallet y cambia a la cadena correcta.
4. El SDK comprueba el saldo antes de permitirle enviar.
5. El cliente firma; se dispara onSuccess.
6. Su servidor confirma el pago y completa el pedido.

Los pasos 2 a 5 son tarea del SDK. El paso 6 es tarea suya, y es el que se suele omitir.

Por qué el paso 6 no es opcional

onSuccess significa que la wallet aceptó la transacción y la difundió. No significa que el dinero haya llegado. La transacción puede fallar, ser reemplazada por otra con una comisión más alta o descartarse del mempool.

Además, se ejecuta en el cliente, así que cualquiera que pueda abrir la consola del navegador en su página de checkout puede activarlo. Si el navegador decide cuándo se completa un pedido, cualquiera puede pedir que se complete.

onSuccess={(paymentId, txHash) => {
  // Right: hand it to your server and let the server decide.
  fetch('/api/orders/awaiting-confirmation', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ paymentId, txHash }),
  });

  // Wrong: fulfilling here trusts the browser.
  // grantAccess();
}}

Después, confirme en el servidor, ya sea por webhook o leyendo el estado con su clave.

Comprobaciones de saldo

El SDK comprueba que el cliente tiene suficiente cantidad del token, y suficiente moneda nativa para el gas, antes de permitir el envío. Así se detecta el fallo más común, tener USDC pero no ETH para el gas, antes de intentar la transacción y no después de que se revierta.

Importes que no coinciden

Un cliente puede enviar más o menos de lo facturado. Ninguno de los dos casos rompe el pago, y ambos tienen un tratamiento definido: consulte Sobrepagos y reembolsos.