Aprender a obtener una concesión para un pago entrante desde un wallet address es el primer paso para construir flujos de pago programables con Interledger. Aquí verás cómo conectar dos billeteras de prueba, solicitar un grant al auth server y dejar listo el terreno para crear un incoming payment.

¿Qué hace el método client.walletAddress.get en un flujo de pago?

El método client.walletAddress.get consulta el endpoint de una dirección de billetera y devuelve la información necesaria para iniciar la transacción. Cada URL expuesta pertenece a una billetera dentro del entorno de pruebas y, además de identificar al usuario, indica qué métodos de pago soporta.

En este flujo intervienen dos actores claros:

• Alicia, la billetera que envía el pago.
• Bob, la billetera que recibe el pago.
• El auth server del testdev de Interledger, que autoriza la operación.

Al ejecutar la consulta para ambas direcciones obtienes datos como el asset code en dólares, la escala decimal en 2, el public name del receptor y las capacidades de cada billetera (enviar, recibir o autenticar). Para verificar que todo llegó bien, imprimes los dos objetos con console.log usando las variables sendingWalletAddress y receivingWalletAddress.

¿Qué es un wallet address en Interledger? Es una URL pública que representa una billetera y expone su información de pagos: moneda soportada, escala, nombre público y capacidades de envío o recepción.

¿Cómo se solicita un grant para crear un incoming payment?

Un grant es el permiso que el auth server otorga para ejecutar una acción específica sobre una billetera. En este caso, el objetivo es crear un incoming payment en la dirección de Bob, así que la solicitud parte desde su wallet address.

El flujo paso a paso queda así:

1. Desde la wallet address del receptor descubres el authorization server asociado.
2. Construyes el grant request indicando el tipo de recurso que quieres gestionar.
3. Envías la solicitud al auth server y esperas el access token.

Dentro del body de la petición defines el acceso de forma muy puntual: el recurso es un incoming payment y la única acción permitida es create. Esa precisión es clave, porque limita lo que el token podrá hacer y refuerza la seguridad de la operación.

¿Por qué se restringe el access token a una sola acción?

Restringir el access token a create evita que ese mismo permiso se use para listar, modificar o leer otros pagos. Así, cada token cumple una función específica dentro del flujo y reduce el riesgo si algo se filtra.

¿Qué incluye la respuesta del auth server cuando aprueba un grant? Devuelve un grant finalizado con un access token utilizable, listo para hacer el POST que crea el incoming payment del receptor.

¿Cómo verificar que el grant esté finalizado antes de continuar?

Antes de seguir, conviene comprobar el estado de la concesión. Si el servidor la aprueba de inmediato, responde con un grant finalizado que ya no requiere pasos de interacción adicionales. Si no, debes lanzar un error que indique que se espera la finalización del grant.

Esta validación protege el flujo de dos formas:

• Confirma que no faltan pasos de autenticación pendientes.
• Garantiza que el access token recibido es realmente utilizable.

Al ejecutar node index.js en la terminal puedes ver la salida en consola: el asset code en dólares, la escala 2, el public name de Bob y la confirmación de que existe una autorización activa contra el auth server del testdev de Interledger. Si todo aparece en orden, la concesión quedó obtenida con éxito.

¿Qué sigue después de obtener el grant?

Con el grant finalizado y el access token en mano, el siguiente movimiento es hacer el POST que crea el incoming payment en la billetera del receptor. Ese llamado es el que habilita formalmente la recepción del pago y conecta a Alicia con Bob dentro del flujo de Interledger.

Si ya probaste este paso en tu terminal, cuéntame qué datos te devolvió tu wallet address y si pudiste validar la concesión sin errores.