Pakistán: Raast, JazzCash y easypaisa sin confundir transferencia con adquirencia

«Pedido pagado por JazzCash»: esa frase no basta para conciliar, y con easypaisa ocurre lo mismo. El comprador pudo hacer una transferencia, pagar a través de una pasarela de pago comercial o recibir un token para pagar después. Del mismo modo, Raast puede aparecer dentro de la aplicación de otro proveedor. La marca en el teléfono no equivale al tipo de operación, y la aparición de instrucciones de pago no equivale a recibir el dinero.

Para un equipo que atiende a comercios legítimos en Pakistán conviene construir un mapa por funciones: hacia dónde se dirige el pago, quién confirma el resultado, dónde están los fondos y con qué mecanismo se devuelven. Aquí Raast, JazzCash y easypaisa se tratan como sistemas y servicios relevantes y disponibles, sin un ranking de popularidad no demostrado.

Raast ID y merchant alias resuelven tareas distintas

El SBP describe el Raast ID para P2P como un número móvil vinculado a una cuenta. La transferencia puede dirigirse a un ID registrado o a un IBAN; para enviar no se necesita un Raast ID propio. Las preguntas frecuentes para personas físicas indican que un ID se vincula a una sola cuenta y que es posible volver a vincularlo. En esta descripción, el riel en sí está pensado para transferencias nacionales, y los límites concretos deben consultarse con el banco.

Conclusión práctica: el teléfono no puede guardarse como prueba permanente del destino bancario. Se necesitan el resultado de la verificación del beneficiario y una instantánea de los datos de pago entregados en cada intento. Si la organización cobra por bienes o servicios, el expediente de alta debe dejar claro por qué se usa precisamente ese tipo de cuenta y de contrato. El alias personal de un empleado no se convierte en infraestructura comercial por integrarlo en la caja.

Raast P2M contempla QR, merchant alias, IBAN y Request to Pay con plazo de pago inmediato o diferido. El SBP exige verificar el negocio en el alta y poder procesar solicitudes de devolución que el comercio acepta o rechaza. Se prevén notificaciones inmediatas de confirmación o rechazo. Son requisitos para los participantes, no una prueba de que cualquier banco ya haya habilitado todas las funciones para su empresa. Circular sobre P2M.

Request to Pay es una propuesta de pago, no un cargo

Dentro de la caja, separe la creación de la solicitud del consentimiento del pagador y del resultado financiero. Para el registro propio resultan útiles el order ID, el attempt ID, el identificador de la solicitud en el proveedor, el plazo de vigencia, el importe esperado, el beneficiario y el transaction reference final. Es un modelo de datos recomendado; los nombres concretos de los campos de la API los define su MSP, no este artículo.

Caso de estudio: el cliente abrió una solicitud Later y luego envió por su cuenta una transferencia al IBAN. Si el procesamiento sigue tratando ambos caminos como pedidos independientes, pueden producirse un doble pago y una doble entrega. Hace falta una política para emparejar los intentos alternativos de un mismo pedido. El pago excedente confirmado se gestiona por separado: no se diluye en el siguiente pedido del cliente ni se envía a un destinatario cualquiera sacado de un chat.

JazzCash: conserve la semántica exacta de los campos

En la documentación publicada de la pasarela, pp_TxnRefNo lo asigna el comercio, pp_Amount se envía sin separador decimal en la escala monetaria acordada y pp_TxnCurrency contiene PKR. También se usan plazos de la operación y pp_SecureHash. La devolución se vincula a la operación original mediante la reference. Es una versión publicada concreta de la interfaz: antes de pasar a production hay que cotejarla con la especificación que le entregaron, incluida la firma y el orden de los estados.

Un error en la escala del importe resulta especialmente caro. Una prueba de 100 PKR debe verificar no solo la pantalla del comprador, sino también la solicitud, la respuesta, el informe y el movimiento bancario. Copiar una cifra de un formato a otro sin comprobarla puede producir una diferencia de cien veces. Guarde el importe en un formato interno inequívoco y conviértalo en el límite de la integración, con pruebas separadas para cada versión de la API.

En su descripción del alta, JazzCash menciona la verificación de documentos, la biometría, la firma del contrato y el registro a nombre del negocio; en eligibility figuran el CNIC y el NTN. Tener una billetera consumer no sustituye estas etapas. La lista de métodos de pago disponibles en la pasarela incluye cuenta móvil, tarjetas y vouchers, así que el nombre JazzCash por sí solo no determina el instrumento con el que se financia la compra.

easypaisa: un token no es un pago confirmado

El merchant FAQ de easypaisa enumera entre los métodos de la pasarela Mobile Account y OTC: un token que se paga en los puntos y canales bancarios indicados. Para el equipo de operaciones es fundamental mantener un estado propio de «pago del token pendiente». No se puede acreditar dinero al crearlo. El plazo de espera, la posibilidad de volver a pagar y el estado definitivo deben tomarse de su especificación vigente.

Las condiciones de easypaisa para pasar de retailer a merchant describen por separado el contrato con el banco, el uso para bienes y servicios legales, los límites asignados y la posibilidad de débitos de corrección. Es un buen contraejemplo de la promesa «si llegó a la billetera, ya nadie lo toca». El documento no permite declarar cualquier operación como irreversible sin condiciones ni trasladar los derechos de agente a la aceptación comercial.

Dónde surge la verdadera carga operativa

El piloto debe incluir algo más que pagos exitosos. Deje una solicitud sin pagar, cierre el navegador después de la autorización, compruebe una notificación repetida, consulte el estado tras un timeout y realice una devolución acordada. En cada prueba, anote quién tiene la confirmación final y cómo la obtiene el operador de noche. Si soporte solo ve el SMS del cliente, la fiabilidad del proceso aún no está demostrada.

Concilie la liquidación al comercio por separado del pago del cliente. El contrato debe explicar comisiones, retenciones, saldo disponible, cuenta bancaria de destino y plazos después de los fines de semana. Que la aceptación se describa como «real-time» no promete la misma disponibilidad para todos los retiros. Una devolución sobre la operación original y un nuevo pago saliente también requieren fundamentos e identificadores distintos.

Una licencia de servicios de pago no autoriza juegos de azar

El Pakistan Code contiene legislación específica para prevenir los juegos de azar. Por eso, una licencia de gambling extranjera y la conexión a una billetera regulada no acreditan que ese negocio sea admisible en Pakistán. Este análisis de métodos técnicos no es una ruta para eludir restricciones. Antes del lanzamiento comercial se necesitan bases locales aplicables para la actividad y la aprobación explícita de la categoría por parte de la entidad que presta el servicio.

Una buena integración se puede explicar en una sola frase con detalles verificables: quién paga, a quién, en qué producto, con qué fundamento y con qué mensaje se confirma el resultado. Si en su lugar solo queda «el socio local lo resolverá todo», el riesgo no se ha eliminado: se ha ocultado al comercio.