Compra de producto tarifario posterior al aprovisionamiento en la billetera

El flujo de trabajo de Compra de Producto Tarifario Posterior a la Aprovisionamiento en Wallet es iniciado por el usuario a través de la aplicación Wallet. El objetivo principal es que el usuario compre o renueve un producto tarifario y que este se aplique sin problemas a su tarjeta de transporte en Apple Wallet para su uso inmediato.

Flujo de trabajo

Los siguientes pasos a alto nivel describen el flujo de trabajo de Compra de Producto Tarifario Posterior a la Aprovisionamiento en Wallet:

Selección de Producto Tarifario: El usuario selecciona el producto tarifario que desea comprar. Las opciones pueden incluir añadir valor almacenado a un saldo existente o comprar/renovar un plan de desplazamiento.

Pago: Una vez que el usuario autoriza la compra del producto tarifario seleccionado, el Gestor de Pagos procesa el pago.

Actualización del Applet y Actualización de la Visualización en Wallet: En el contexto CBT, existe la necesidad de actualizar el contenido del applet. Al recibir la solicitud updateBundle con la intención "applet update", el dispositivo Apple solicita obtener los comandos que deben ejecutarse para actualizar los datos de contenido del applet.

Para compras de nuevos productos, es necesario actualizar la visualización en Wallet. Al recibir la solicitud updateBundle con la intención "pass update", Apple solicita el paquete de aprovisionamiento que contiene los detalles de la tarjeta a D1 Transit.

Fare Product Selection

Error Scenarios

Renewal not permitted

Apple Wallet includes a "renew" button for fare products, which becomes available based on the Transit Issuer's business rules. For instance, a monthly pass might be eligible for renewal only within a window that starts 3 days before its expiration and ends 3 days after expiration.

When the user selects the "renew" button, if the cohabitation rule engine determines that renewal options are not allowed due to business rules, D1 Transit must notify Apple by returning a response with an empty cardActions array. This indicates that no renewal actions are available for the selected card.

Purchase not permitted

If the cohabitation rule engine determines that no products are available to purchase due to business rules, D1 Transit must notify Apple by returning a response with an empty cardActions array. This indicates that no purchase actions are available for the selected card.

Payment

Upon the user authorizing the payment, a performPayment API call is triggered and sent to D1 Transit platform, which sends a purchaseProducts request to Transit Issuer. Transit Issuer is responsible for ensuring the payment request is processed by the PSP.

After processing, the outcome of the transaction is communicated back to the Apple. If the payment is successfully processed, D1 Transit returns a Purchase object with its state set to complete.

Error scenarios

When a payment failure or timeout occurs, Apple Wallet displays a red exclamation mark to the user. The user can retry the payment using the same or a different payment sheet, with either the same or a different payment credential.

retry with same payment sheet

In this case, the same orderId will be used. Transit issuer needs to check the status of the payment linked to that orderId. It's possible that the existing payment was successfully processed by the PSP, but due to a delay, the previous attempt timed out.

retry with a different payment sheet

Here, a new orderId is generated for this new payment request.

Actualización del Applet y Actualización de la Visualización en Wallet

Después de comprar o renovar con éxito un producto tarifario, D1 Transit notifica a Apple realizando una solicitud API updateBundle, con el parámetro intentionType establecido en updateApplet.

Al recibir la solicitud updateBundle, Apple inicia el comando "redirect" hacia el dispositivo. El dispositivo se conecta a D1 Transit para obtener los comandos que deben ejecutarse para actualizar el contenido de datos del applet. Pueden producirse varios viajes de ida y vuelta para ello.

Una vez que los datos del applet se actualizan, D1 Transit notifica al Emisor de Transporte que los datos del paquete se actualizaron correctamente.

Para los nuevos productos comprados, después de recibir la notificación de datos de paquete exitosa, el Emisor de Transporte envía un handleEvent a la plataforma D1 Transit para actualizar la visualización en la wallet.

D1 Transit notifica a Apple realizando una solicitud API updateBundle, con el parámetro intentionType establecido en updatePass.

Al recibir la solicitud updateBundle, Apple recupera el paquete de aprovisionamiento realizando una solicitud getProvisioningBundle a D1 Transit.

Una vez que el paquete es devuelto a Apple, D1 Transit notifica al Emisor de Transporte que el paquete se actualizó correctamente.

Escenarios de Error

No hay solicitud de Apple para obtener el paquete de aprovisionamiento

D1 Transit define un período de tiempo de espera entre la recepción de la respuesta updateBundle y la solicitud getProvisioningBundle por parte de Apple.

Si la solicitud getProvisioningBundle no es recibida por D1 Transit dentro de este período de tiempo de espera, D1 Transit aplicará una política de reintentos configurada.

Si se agotan todos los intentos de reintento y la solicitud getProvisioningBundle aún no es recibida, Thales escala el problema contactando a Apple para una investigación y resolución adicionales.

Dado que esta integración utiliza ABT, los productos tarifarios vinculados a la tarjeta se almacenan en el servidor, lo que significa que no debería ser necesario reembolsar al cliente si la actualización del paquete falla.

Solicitud de paquete de aprovisionamiento recibida después del tiempo de espera

En los casos en que la solicitud getProvisioningBundle se recibe después del tiempo de espera, D1 Transit verifica primero si el triggeringRequestIdentifier está vinculado a un requestIdentifier updateBundle que previamente caducó. Si la solicitud está asociada con un updateBundle caducado, D1 Transit devuelve un estado HTTP 200 a Apple, estableciendo el statusCode en HTTP 500. Esta respuesta informa a Apple que no son necesarias más actualizaciones para la tarjeta