En el mundo de los Pagos estándar de Google, la Facturación del operador de telefonía celular se considera una forma de pago (FOP) con token, es decir, Google y el integrador de pagos realizan un intercambio único de credenciales de identidad de la cuenta para establecer un token. Más adelante, este token se presenta de nuevo a la integración de pagos para identificar la cuenta a la que se cobrará.
Otras formas de pago también usan la asignación de token. Por lo tanto, ofrecemos una descripción general de las FOP con token que es principalmente relevante para la Facturación del operador. Los flujos de autenticación, asociación, compra y remesa se describen con más detalle en esa descripción general. En esta página, se proporcionan más detalles sobre la facturación del operador de telefonía celular.
Los operadores se incorporan a los pagos estándar de Google mediante la implementación de las APIs que componen los siguientes flujos:
| Flujo | Descripción | Equivalente de especificaciones de DCB3 |
|---|---|---|
| Autenticación | Identifica y autentica la cuenta del usuario en el sistema del integrador de pagos que se usará para realizar pagos de DCB | SMS-MO con GoogleUserToken |
| Asociación | Intercambia un token de larga duración que Google y el Integrador de pagos acuerden para realizar pagos con la cuenta de Integrador de pagos del usuario. | aprueba la devolución de llamada de usuario con OperatorUserToken y GetProvisioning() |
| FundsTransfer | Mueve fondos de forma síncrona fuera de la cuenta de integrador de pagos del usuario. Transfiere la responsabilidad al integrador de pagos. | Líneas Auth() y CHARGE en archivos de solicitud por lotes |
| Reembolso | De manera síncrona, muestra algunos o todos los fondos asociados a una transferencia de fondos anterior a la cuenta del integrador de pagos del usuario. Transfiere la responsabilidad a Google | Líneas de REEMBOLSO en archivos de solicitud por lotes |
| Remesas | Liquidación basada en la API, preferentemente diaria | Factura mensual en PDF, archivo de detalles de la factura mensual, archivo de reconocimiento diario |
| UpdateAssociatedAccount | Informa a Google sobre los cambios en la cuenta de integrador de pagos de un usuario (p. ej., límites de transacciones o estado de aprovisionamiento). | Encuesta de GetProvisioning() |
| Fraude | Informa a Google sobre las transacciones que se revirtieron debido a una impugnación de un usuario. Esto se usa para mejorar el motor de riesgos de Google, pero no afecta la responsabilidad monetaria. | Ninguna |
Comparación general con las especificaciones de DCB3
La especificación de Pagos estándar de Google resuelve los mismos problemas que resuelve la especificación DCB3. Sin embargo, usa diferentes tecnologías y diseños de API que mejoran la solución. Estas son las principales diferencias a simple vista:
Comparación de tecnología de pila
Toda la comunicación de la API se realiza mediante POST HTTPS con JSON firmado y encriptado con PGP. Esto significa que Google y el integrador de pagos tienen solo una clave de PGP para rotar. Estas tecnologías también tienen mejor compatibilidad que SOAP. Puedes encontrar más detalles sobre la pila de comunicación.
Comparación de la filosofía de las APIs
DCB3 depende en gran medida de los archivos para conciliar el estado de pago. Google Standard Payments no tiene archivos. Las llamadas a la API se reintentan de forma idempotente e indefinidamente hasta que se determina un estado final.
Los estados finales son realmente definitivos para una clave de idempotencia específica. Los errores y los estados indeterminados no se modelan como rechazos, sino como respuestas HTTP que no son 200. Esto nos permite detectar errores más rápido y evitar enmascararlos a medida que disminuyen.
Nuevas funciones
Los Pagos estándar de Google admiten funciones nuevas, como las siguientes:
- la API de Fraud para informar al motor de riesgos de Google sobre fraudes
- Actualiza la API de Associated Account para informar a Google sobre el aprovisionamiento, los límites de transacciones y los cambios en el estado de la cuenta
- Mayor compatibilidad de verificación de autenticación durante compras, como PINs de USSD
- Ciclo de remesas diario
Mapa de terminología de DCB3 a Google Standard Payments
En esta documentación y en la especificación en sí, verás terminología que parece nueva, pero que, en realidad, es solo palabras diferentes para los conceptos existentes.
- Proveedor -> Integrador de pagos
ADVERTENCIA: Para evitar confusiones con el concepto del integrador de DCB, en este documento, se intenta usar “Integrador de pagos” y “Integrador de DCB” en lugar de solo “integrador”. Sin embargo, en la documentación general de Pagos estándar de Google, se usa "integrador" de forma generosa como abreviatura de "Integrador de pagos".
- ID del acuerdo de facturación -> ID de la cuenta de integrador de pagos
- OperadorUserToken (OUT) -> GooglePaymentToken (GPT)
- mapping_id -> requestId
- Reparto de ingresos -> tarifa
Flujo de autenticación
A fin de obtener una descripción general del flujo de autenticación para las FOP con token, consulta esta página.
Especificaciones sobre la facturación del operador
En el caso de la Facturación del operador, el objetivo del flujo de autenticación es demostrar que el usuario tiene el control de la tarjeta SIM vinculada a la cuenta del operador. Los usuarios de la facturación del operador de telefonía celular se pueden autenticar mediante cualquiera de estos tres mecanismos:
- Autenticación por SMS-MO (definición en la descripción general de las FOP con token)
- Autenticación de redireccionamiento (definición en la descripción general de las FOP con token)
- OTP de SMS-MT (Definición en FOP con token)
Los integradores de pagos pueden trabajar con Google para elegir los mecanismos de autenticación que mejor se adapten a sus productos.
Comparación con DCB3
El flujo de autenticación reemplaza la devolución de llamada de approveuser a Google por
fuera de la especificación de DCB3.
En DCB3, la autenticación y asociación se combinaron en un solo flujo. En Google Standard Payments, la autenticación es una preocupación diferente de la asociación de cuentas.
Flujo de asociación
A fin de obtener una descripción general del flujo de asociación para las FOP con token, consulta esta página.
La diferencia principal entre el flujo de asociación que se usa para los instrumentos de Facturación del operador y el flujo general de FOP con token es que la prueba de autenticación proporcionada en el método associateAccount variará en función de si el integrador de pagos solicitó una verificación adicional del usuario.
Si el integrador de pagos respondió que solicitaba un desafío adicional para el usuario, la prueba de autenticación será cualquier prueba de identidad que produzca el mecanismo de autenticación particular que Google haya usado para el desafío adicional. Por ejemplo, la prueba de autenticación que produce el mecanismo de OTP de SMS-MT es el requestId de un método sendOtp, más la OTP.
Atributos del instrumento
En la sección general de atributos del instrumento de la descripción general de las FOP con token se analiza el concepto de accountAlias, accountNickname y fullAccountNickname.
Especificaciones sobre la facturación del operador
accountAliasdebe ser el número de teléfono del usuario. Se usará para identificar el instrumento en caso de que el usuario llame a Atención al cliente de Google con respecto a su cuenta.accountNicknameyfullAccountNicknameson nombres visibles que se usan para identificar el instrumento en la IU.
Comparación con las especificaciones de DCB3
El flujo de asociación reemplaza los siguientes componentes de la especificación de DCB3:
- Llamada SOAP de GetProvisioning
- Llamada SOAP GetSubscriberAddress
- OUT generado por el operador
Una gran diferencia aquí es el hecho de que Google genera el token de Google Payment (GPT) durante el flujo de asociación, en lugar de hacerlo mediante el proveedor.
También es importante tener en cuenta que, a diferencia de DCB3, en la que los OUTS tienen alcance en un BillingAgreementId en particular, la GPT no tiene alcance en un PaymentIntegratorAccountID en particular.
Flujo de actualización de tokens
A fin de obtener una descripción general del flujo de tokens de actualización para las FOP con token, consulta esta página.
Especificaciones sobre la facturación del operador
En el caso de los instrumentos de Facturación del operador de telefonía celular, no recomendamos que los tokens de pago de Google venzan nunca, ya que esto genera la cancelación de pedidos de suscripción. En lugar de expirar los tokens y depender del flujo de tokens de actualización para corregirlos, a menudo, tu caso de uso se puede lograr mediante el flujo de actualización de cuentas que se describe a continuación.
Flujo de actualización de la cuenta
El flujo de actualización de la cuenta permite que el integrador de pagos informe a Google sobre las actualizaciones de la cuenta del integrador del usuario. Originalmente, estos campos se suministran a Google durante el flujo de asociación. Estos son algunos ejemplos de datos de la cuenta que el integrador de pagos podría querer actualizar:
- Los límites de transacciones mensuales, diarias y por artículo del usuario
- el estado de aprovisionamiento de la cuenta del integrador del usuario
- el tipo de cuenta del integrador del usuario (prepago, pospago, empresarial, etc.)
- el "accountAlias", "accountNickname" o "fullAccountNickname" del usuario
- si el usuario configuró, quitó o cambió un PIN estático precompartido
- si el usuario cerró su cuenta o cambió su número de teléfono (lo cual invalida el instrumento del usuario en el sistema de Google).
- flujo de eliminación de tokens
Comparación con las especificaciones de DCB3
El flujo de actualización de la cuenta reemplaza los siguientes componentes de la especificación de DCB3:
- Sondeo de la llamada SOAP de GetProvisioning
- Invalidación periódica de token
Flujo de compra
Para obtener una descripción general del flujo de compra de las FOP con token, consulta esta página.
Especificaciones sobre la facturación del operador
Algunos operadores usan USSD o alguna otra tecnología para obtener un PIN de sus usuarios durante cada compra. En el caso de estos operadores, en lugar de llamar a capture(), se llama a asíncronoCapture() y se permiten 30 segundos para que el operador solicite al usuario su PIN y finalice la captura. Cuando se determina el estado final del pago, el operador debe llamar a captureResultNotification() para informar a Google el resultado.
Comparación con las especificaciones de DCB3
Aquí hay cambios importantes.
- Llamada de método única y síncrona -- capture() en lugar de auth() + archivo por lotes
- No hay ningún archivo por lotes
- Sin método cancel() (captura + reembolso en lugar de autenticación + cancelación)
- No hay ningún campo user_message en la respuesta: los códigos de rechazo se asignan a mensajes de Google localizados al idioma de la cuenta del usuario.
- Cambios en la terminología clave:
- CorrelationId -> requestId
- IDAcuerdo de Facturación -> paymentIntegratorAccountId
- OperadorUserToken -> googlePaymentToken
Flujo de compra desafiante
El desarrollo está en curso para admitir un flujo de compra que incluye un desafío de autenticación para el usuario antes de cada compra. La mayoría de los métodos de autenticación que se pueden usar antes del flujo de asociación también podrían usarse antes del flujo de compra desafiante para proporcionar autenticación adicional al usuario.
Flujo de reembolso
A fin de obtener una descripción general del flujo de reembolso para las FOP con token, consulta esta página.
La FOP con token admite un flujo de reembolso de mensaje único. Esta opción permite reembolsar una compra completa o una parte de una compra. Si se realizan varios reembolsos parciales, se puede reembolsar una sola compra.
Especificaciones sobre la facturación del operador
Los instrumentos de Facturación del operador de telefonía celular no tienen nada especial en el flujo de reembolso.
Comparación con las especificaciones de DCB3
Los reembolsos se activan mediante una llamada síncrona a la API en lugar de un archivo. Además, se pueden crear varios reembolsos parciales de un solo pago original, en lugar de admitir solo un reembolso de valor completo.
Flujo de remesa
A fin de obtener una descripción general del flujo de remesa para las FOP con token, consulta esta página.
El flujo de remesa es la forma en que Google y el integrador de pagos realizan la liquidación. Google es el sistema contable de registro y se encarga de las transferencias de remesas. Con regularidad, Google envía un resumen de remesas al integrador de pagos. En el resumen, se proporciona un resumen del importe que el integrador de pagos le debe a Google, junto con las instrucciones para pagarle a Google. Para que el integrador de pagos se concilie, este puede consultar a Google los detalles a nivel de la transacción que conforman la declaración de remesa.
Especificaciones sobre la facturación del operador
Las remittanceStatementDetails de la Facturación del operador de telefonía celular incluyen campos adicionales que aún no aparecen en las definiciones de la API del flujo de remesa. Incluye las siguientes herramientas:
- revshareCategory
- itemPrice
- tax
- timestamp
En el caso de los operadores que tienen un acuerdo de división de ingresos de 50/50 con Google, las tarifas que se presentan en remittanceStatementDetails se agregan por revshareCategory, en lugar de presentarse por evento.
Comparación con las especificaciones de DCB3
El flujo de remesa reemplaza los siguientes conceptos en la especificación de DCB3:
- Informe de cargos mensuales/Informe de pago en PDF
- Archivo CSV con los detalles de las facturas mensuales
- Archivos CSV de reconocimiento diario
Las principales diferencias aquí son la eliminación de cualquier archivo y la compatibilidad con las remesas diarias. En lugar de archivos, el importe que se debe remitir se entrega a través de una API síncrona, y otra API admite la consulta de detalles sobre la declaración de remesa.
Flujo de denuncia de fraudes
El flujo de denuncia de fraudes permite que un integrador de pagos informe a Google sobre una transacción potencialmente fraudulenta mediante una llamada al método fraudNotification. Este flujo se usa para actualizar el motor de riesgos interno de Google y no inicia ningún movimiento de dinero.
Especificaciones sobre la facturación del operador
Los instrumentos de Facturación del operador de telefonía celular no tienen nada especial en el flujo de notificación de reversión de pago.