Transacciones con credencial en archivo
Las siguientes secciones describen cómo enviar transacciones iniciadas por el titular de la tarjeta y por el negocio (CIT y MIT) al Mastercard Gateway para cumplir con los estándares del esquema de tarjetas para procesar estas transacciones:
- Pagos iniciados por el titular de la tarjeta:
- Pagos iniciados por el negocio:
Para obtener información general sobre los escenarios anteriores, consulte Pagos iniciados por titulares de tarjetas y negocios. Para ver ejemplos completos de las solicitudes para todos los escenarios, descargue la colección de Postman.
Siempre que envíe varios pagos en una serie, la primera transacción debe ser un CIT que proporcione la aprobación del titular de la tarjeta para toda la serie. Las transacciones posteriores suelen ser MIT. En todas las solicitudes, puede utilizar el campo transaction.source para identificar si una transacción es iniciada por el Titular de la tarjeta o por el negocio, y el campo sourceOfFunds.provided.card.storedOnFile para indicar si los detalles de pago deben almacenarse, han sido previamente almacenados, o tiene la intención de almacenarlos. Para obtener más información, consulte las Preguntas frecuentes.
- Los escenarios anteriores son compatibles desde API v74 en adelante.
- Para poder enviar cualquier MIT, su Your payment service provider (PSP) debe tener MERCHANT habilitado como fuente de transacción permitida en su vínculo de adquirente del negocio.
- Si desea almacenar los detalles de pago del pagador en el motor de pagos y utilizar un token para consultar los detalles almacenados, su PSP debe configurar el perfil del negocio para la tokenización del motor de pagos.
CIT en general
Una transacción CIT puede ser un pago único en el que normalmente no se almacenan los detalles de pago proporcionados por el pagador. Sin embargo, el pagador puede dar su consentimiento para que usted almacene sus datos de pago para uso futuro (normalmente como parte de un proceso de registro de cliente o de creación de cuenta) para que pueda ofrecer transacciones posteriores iniciadas por el titular de la tarjeta utilizando los datos de pago almacenados.
- En la solicitud de transacción inicial con un nuevo cliente, debe proporcionar los siguientes campos:
sourceOfFunds.type = CARD, o bienSCHEME_TOKENEl valor depende de si proporciona los detalles de la tarjeta sin procesar o un token (ya habiendo tokenizado los detalles de la tarjeta).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source = INTERNETEl valor indica al motor de pagos que la transacción la inició el titular de la tarjeta. Puede establecer el valor en
INTERNET,MOTO,MAIL_ORDER,TELEPHONE_ORDER,VOICE_RESPONSEoCALL_CENTER.sourceOfFunds.provided.card.storedOnFile = TO_BE_STOREDEl valor indica que el pagador acepta que usted almacene sus datos de pago para uso futuro.
INTERNET. Sin embargo, debe indicar el canal a través del cual recibió el pago.En cualquier pago posterior iniciado por el pagador (no por usted) y donde se utilizan los detalles de pago almacenados del pagador, debe proporcionar los siguientes campos en la solicitud:
-
sourceOfFunds.type = CARD, o bienSCHEME_TOKENEl valor depende de si los detalles han sido almacenados por usted o por el motor de pagos (en cuyo caso usted proporciona un token).
-
campos de
sourceOfFunds.provided.card.*osourceOfFunds.token -
transaction.source = INTERNET -
sourceOfFunds.provided.card.storedOnFile = STORED
Para obtener más detalles sobre cómo indicar al motor de pagos cómo almacenar los detalles de pago y si esto debe hacerse, consulte las Preguntas frecuentes.
CIT con 3DS
Los CIT se pueden autenticar con 3DS para identificar al titular de la tarjeta y evitar fraudes. Puede usar 3DS en:
- CIT únicos
- CIT que forman el primer paso en una serie de pagos, donde los siguientes son MIT
- Escenarios en los que desea autenticar al titular de la tarjeta al agregar su tarjeta a la cuenta del cliente para uso futuro
La siguiente tabla describe algunos casos de uso detallados relacionados con la autenticación 3DS. Para obtener más información sobre la autenticación 3DS en el motor de pagos y el uso de autorización externa en transacciones de pago, consulte Autenticación 3DS.
| Caso de uso | Pasos de integración |
|---|---|
Acuerdo con el pagador para pagos recurrentes, incluyendo un cargo inicial en el CIT |
Paso 1: Realice la autenticación tal como se describe en las Pautas de autenticación y especifique el monto necesario para el pago inicial. Paso 2: Cree la solicitud de CIT con los detalles definidos en la sección Pagos iniciados por el titular de la tarjeta y agregue uno de los siguientes:
|
|
Acuerdo con el pagador para pagos recurrentes, sin incluir un cargo inicial en el CIT |
Este caso de uso cubre series de pagos recurrentes en las que no se debe realizar ningún pago en el momento en que el pagador se registra en el servicio. Mientras realiza la autenticación como se describe en el tema Autenticación 3DS, utilice los campos adicionales especificados en los siguientes pasos para integrar 3DS para pagos recurrentes. Paso 1: Realice la operación INITIATE AUTHENTICATION y establezca authentication.purpose en ADD_CARD o MAINTAIN_CARD. Paso 2: Realice la operación AUTHENTICATE PAYER con los siguientes campos:
Paso 3: Como la solicitud CIT, realice la solicitud de operación VERIFY y agregue uno de los siguientes valores:
Si está utilizando la integración de Hosted Session, complete los pasos 1 y 2 dentro de la sesión y luego use el ID de sesión (de la sesión creada para los pasos 1 y 2 cuando envíe la solicitud desde su servidor en el paso 3).
|
|
Agregar tarjeta sin acuerdo de pago |
Este caso de uso cubre un escenario en el que el pagador desea agregar los detalles de su tarjeta mientras crea su perfil o cuenta de cliente con usted sin ningún pago inmediato. El pagador puede utilizar la tarjeta guardada en el futuro para pagos únicos o para establecer un acuerdo de pago para una serie de pagos. Paso 1: Realice la operación INITIATE AUTHENTICATION y establezca authentication.purpose en ADD_CARD o MAINTAIN_CARD. Paso 2: Realice la operación AUTHENTICATE PAYER y establezca el monto en 0. Paso 3: Como la solicitud CIT, realice la solicitud de operación VERIFY y agregue uno de los siguientes valores:
Si está utilizando la integración de Hosted Session, complete los pasos 1 y 2 dentro de la sesión y luego use el ID de sesión (de la sesión creada para los pasos 1 y 2 cuando envíe la solicitud desde su servidor en el paso 3).
|
Los siguientes campos son necesarios en la operación AUTHENTICATE PAYER para tener una transacción recurrente exitosa:
- Al utilizar la API v61 o posterior:
- agreement.id
- agreement.type=RECURRING
- agreement.numberOfPayments
- agreement.amountVariability
- agreement.expiryDate
- agreement.paymentFrequency
- agreement.minimumDaysBetweenPayments
Cuando se utiliza la API v57 - v60:
- agreement.id
- agreement.type=RECURRING
- agreement.expiryDate
- agreement.recurring.daysBetweenPayments
CIT con el Hosted Checkout y credenciales almacenadas
Para crear un CIT con Hosted Checkout cuando no existen credenciales almacenadas:
- Envíe una solicitud de operación INITIATE CHECKOUT con
interaction.saveCardForCredentialOnFile = PAYER_INITIATED_PAYMENTS.El Hosted Checkout proporciona al pagador las opciones de pago disponibles en la ventana Opciones de pago.
- Las credenciales en archivo con escenarios de Hosted Checkout se admiten desde API v74 en adelante.
- Si admite el método de pago Click to Pay, el Hosted Checkout no lo muestra por separado en su página de pago. Se solicita al pagador su dirección de correo electrónico y, si el pagador tiene un perfil Click to Pay, las tarjetas que ha almacenado para su perfil se enumeran en la sección Débito o crédito.
- El pagador selecciona Débito o Crédito.
El Hosted Checkout no muestra ni vincula los Términos y condiciones ni las Políticas de privacidad. Es responsabilidad de usted proporcionar estos detalles al pagador según lo exijan las normativas reglamentarias o las leyes de privacidad. - El pagador puede pagar con o sin dar su consentimiento al motor de pagos, es decir, con o sin seleccionar la casilla Guardar esta tarjeta para futuras compras.
- Si el pagador procede al pago sin dar su consentimiento, el proceso de pago funciona como de costumbre.
- Si el pagador procede a pagar dando su consentimiento, entonces el Hosted Checkout:
- Establece el indicador de tarjeta en archivo correcto.
- Envíe la solicitud de transacción PAY (si
interaction.operation=AUTHORIZE) consourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDytransaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS.
Debe cumplir con los requisitos del esquema y las normativas (por ejemplo, GDPR). Debe proporcionar al pagador la opción de eliminar el consentimiento y borrar el token del motor de pagos.
Si el pagador paga con un método que no sea una tarjeta de crédito, como ACH (Automated Clearing House) o PayPal, se aplica el procedimiento de pago estándar. El motor de pagos solo almacena los datos de la tarjeta, por lo que si desea almacenar cualquier detalle de pago relacionado con otros métodos de pago, debe hacerlo usted mismo después de recibir el consentimiento del pagador. - Después de que el motor de pagos devuelva al pagador al sitio web de su tienda, envíe una solicitud de operación
RETRIEVE_ORDER.- Si el pagador ha dado su consentimiento, la respuesta contiene el campo
transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS. - Para crear el token que puede usar para hacer referencia a las credenciales almacenadas en el motor de pagos, use la operación CREATE OR UPDATE TOKEN. Para obtener más detalles, consulte Tokenización del motor de pagos.
- Si el pagador ha dado su consentimiento, la respuesta contiene el campo
- Para cualquier pago posterior iniciado por el titular de la tarjeta, envíe la solicitud de operación INITIATE CHECKOUT con:
interaction.tokensque contiene el token de motor de pagosinteraction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTSEste campo permite al pagador introducir nuevos datos de la tarjeta y almacenarlos, si no desea utilizar los anteriores.
El Hosted Checkout muestra las opciones de pago disponibles y las tarjetas almacenadas para el pagador.
- Si el pagador selecciona Débito o crédito, se enumeran los detalles del token y el pagador puede elegir pagar con el token o agregar los detalles de otra tarjeta.
CIT con el Hosted Checkout para autorizar MIT
Para obtener el consentimiento del pagador con el Hosted Checkout para almacenar sus detalles de pago para MIT posteriores (por ejemplo, creando una cuenta de pagador en su sistema y almacenando los detalles en la cuenta):
- Envíe una solicitud de operación INITIATE CHECKOUT con:
agreement.idValor único generado por usted para identificar un acuerdo de pago con el pagador. Debe enviarlo en MIT posteriores para vincular los pagos en una serie. Esto es necesario para cumplir con los mandatos del esquema de tarjetas donde el ID del acuerdo actúa como un identificador para vincular el CIT anterior con los MIT posteriores.
agreement.typeClase de acuerdo comercial que se ha establecido con el pagador.
- Las credenciales en archivo con escenarios de Hosted Checkout se admiten desde API v74 en adelante.
- Los detalles del acuerdo solo son necesarios si tiene la intención de procesar las MIT relacionadas con las CIT más adelante. Si solo tiene intención de procesar las CIT con los datos de pago almacenados, no es necesario ningún acuerdo.
El Hosted Checkout proporciona al pagador las opciones de pago con tarjeta de débito o crédito.
- Debe cumplir con los requisitos del esquema y las normativas, por ejemplo, GDPR. Debe proporcionar al pagador la opción de retirar el consentimiento y eliminar las credenciales almacenadas.
- Es su responsabilidad asegurarse de que los artículos que no necesitan acuerdos no se incluyan en el pedido o transacción.
- El pagador puede continuar solo dando su consentimiento, es decir, seleccionando la casilla de verificación. El botón de pago está deshabilitado hasta que selecciona la casilla de verificación.
Si el pagador continúa dando su consentimiento, el Hosted Checkout envía la solicitud de transacción con los siguientes valores:
sourceOfFunds.provided.card.storedOnFile = TO_BE_STOREDtransaction.payerConsentForStoringCardDetails = MERCHANT_INITIATED_PAYMENTS
- Después de que el motor de pagos devuelva al pagador a su sitio web, envíe una solicitud de operación RETRIEVE ORDER:
- Si el pagador ha dado su consentimiento, la respuesta contiene el campo
transaction.payerConsentForStoringCardDetails = MERCHANT_INITIATED_PAYMENTS. - Si el pagador no ha dado su consentimiento, el pagador no puede continuar (el carrito se abandona).
- Si el pagador ha dado su consentimiento, la respuesta contiene el campo
Pagos recurrentes iniciados por el negocio
Puede enviar pagos recurrentes para su procesamiento al motor de pagos si el pagador acepta que usted almacene sus datos de pago para uso futuro y tiene un acuerdo de pago con el pagador que le autoriza a iniciar pagos recurrentes posteriores sin la participación activa del pagador.
En la solicitud inicial de CIT, debe proporcionar los siguientes campos para configurar el acuerdo:
sourceOfFunds.type=CARDoSCHEME_TOKENEl valor depende de si proporciona los detalles de la tarjeta sin procesar o un token (ya habiendo tokenizado los detalles de la tarjeta).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=INTERNET, andEl valor indica al motor de pagos que la transacción la inició el titular de la tarjeta.
sourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDEl valor indica que el pagador acepta que usted almacene sus datos de pago para uso futuro.
agreement.idValor único generado por usted para identificar un acuerdo de pago con el pagador.
agreement.type=RECURRINGAcuerdo de instrucción permanente que haya establecido con el pagador.
- Cuando se utiliza la API v61 y posteriores:
agreement.numberOfPaymentsagreement.amountVariabilityagreement.expiryDateagreement.paymentFrequencyagreement.minimumDaysBetweenPayments
- Cuando se utiliza la API v57 - v60:
agreement.expiryDateagreement.recurring.daysBetweenPayments
En cualquier solicitud MIT posterior, debe proporcionar los siguientes campos:
sourceOfFunds.type=CARDoSCHEME_TOKENEl valor depende de si los detalles han sido almacenados por usted o por el motor de pagos (en cuyo caso usted proporciona un token).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=MERCHANTEl valor indica al motor de pagos que la transacción la inicia el negocio.
sourceOfFunds.provided.card.storedOnFile=STOREDagreement.idEl valor debe ser el mismo agreement.id que el proporcionado en la transacción CIT inicial. Esto permite que el motor de pagos vincule los pagos en una serie y debe cumplir con los mandatos del esquema de tarjetas donde el ID del acuerdo actúa como un identificador para vincular la CIT anterior con las MIT posteriores.
Pagos en números de pagos iniciados por el negocio
Puede enviar número de pagos para su procesamiento al motor de pagos si el pagador acepta que usted almacene sus detalles de pago para uso futuro y tiene un acuerdo de pago con el pagador para dividir una compra única en una cantidad de pagos procesados en intervalos acordados.
En la solicitud inicial de CIT, debe proporcionar los siguientes campos para configurar el acuerdo:
sourceOfFunds.type=CARDoSCHEME_TOKENEl valor depende de si proporciona los detalles de la tarjeta sin procesar o un token (ya habiendo tokenizado los detalles de la tarjeta).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=INTERNETEl valor indica al motor de pagos que la transacción la inició el titular de la tarjeta.
sourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDEl valor indica que el pagador acepta que usted almacene sus datos de pago para uso futuro.
agreement.idValor único generado por usted para identificar un acuerdo de pago con el pagador.
agreement.type=INSTALLMENTAcuerdo de instrucción permanente que haya establecido con el pagador.
- Cuando se utiliza la API v61 y posteriores:
agreement.numberOfPaymentsagreement.amountVariabilityagreement.expiryDateagreement.paymentFrequencyagreement.minimumDaysBetweenPayments
- Cuando se utiliza la API v57 - v60:
agreement.expiryDateagreement.recurring.daysBetweenPayments
En cualquier solicitud MIT posterior, debe proporcionar los siguientes campos:
sourceOfFunds.type=CARDoSCHEME_TOKENEl valor depende de si los detalles han sido almacenados por usted o por el motor de pagos (en cuyo caso usted proporciona un token).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.tokenEl valor indica al motor de pagos que la transacción la inicia el negocio.
transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDagreement.idEl valor debe ser el mismo
agreement.idque el proporcionado en la transacción CIT inicial. Esto permite que el motor de pagos vincule los pagos en una serie y debe cumplir con los mandatos del esquema de tarjetas donde el ID del acuerdo actúa como un identificador para vincular la CIT anterior con las MIT posteriores.
Pagos no programados iniciados por el negocio
Puede enviar pagos no programados para su procesamiento al motor de pagos si el pagador acepta que usted almacene sus datos de pago para uso futuro y tiene un acuerdo de pago con el pagador que le autoriza a iniciar pagos no programados posteriores sin la participación activa del pagador.
En la solicitud inicial de CIT, debe proporcionar los siguientes campos para configurar el acuerdo:
sourceOfFunds.type=CARDoSCHEME_TOKENEl valor depende de si proporciona los detalles de la tarjeta sin procesar o un token (ya habiendo tokenizado los detalles de la tarjeta).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=INTERNETEl valor indica al motor de pagos que la transacción la inició el titular de la tarjeta.
sourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDEl valor indica que el pagador acepta que usted almacene sus datos de pago para uso futuro.
agreement.idValor único generado por usted para identificar un acuerdo de pago con el pagador.
agreement.type=UNSCHEDULEDAcuerdo de instrucción permanente que haya establecido con el pagador.
- Cuando se utiliza la API v61 y posteriores:
agreement.numberOfPaymentsagreement.amountVariabilityagreement.paymentFrequency
- Cuando se utiliza la API v57 - v60:
agreement.expiryDateagreement.recurring.daysBetweenPayments
En cualquier solicitud MIT posterior, debe proporcionar los siguientes campos:
sourceOfFunds.type=CARDoSCHEME_TOKENEl valor depende de si los detalles han sido almacenados por usted o por el motor de pagos (en cuyo caso usted proporciona un token).
- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=MERCHANTEl valor indica al motor de pagos que la transacción la inicia el negocio.
sourceOfFunds.provided.card.storedOnFile=STOREDagreement.id: el mismo agreement.id que el proporcionado en la transacción inicial. Esto permite al motor de pagos vincular los pagos de una serie.El valor debe ser el mismo agreement.id que el proporcionado en la transacción CIT inicial. Esto permite que el motor de pagos vincule los pagos en una serie y debe cumplir con los mandatos del esquema de tarjetas donde el ID del acuerdo actúa como un identificador para vincular la CIT anterior con las MIT posteriores.
Pagos de prácticas de la industria iniciados por el negocio
Puede enviar pagos de prácticas de la industria para su procesamiento al motor de pagos si el pagador le permite almacenar sus detalles de pago para uso futuro y lo autoriza a iniciar MIT posteriores sin la participación activa del pagador.
En la solicitud de MIT de práctica de la industria, debe proporcionar los siguientes campos:
order.industryPracticePaymentReasonTipo de pago de la industria que está creando, por ejemplo, DELAYED_CHARGE, NO_SHOW_PENALTY o PARTIAL_SHIPMENT.
sourceofFunds.provided.card.storedOnFiles = STOREDEl valor indica que el pagador ha aceptado que usted almacene sus datos de pago para uso futuro.
referenceOrderIdID de pedido de la CIT anterior. El motor de pagos utiliza este campo para buscar el ID de pista de la CIT anterior.
transaction.acquirer.traceidID de pista. Este campo contiene el authorizationResponse.transactionIdentifier de la respuesta de la CIT inicial de la serie. Este campo solo es necesario si el ID del pedido de referencia no está disponible. Si proporciona el ID del acuerdo y no proporciona el ID del pedido de referencia o el ID de pista en las tarjetas Mastercard procesadas, el motor de pagos proporcionará un ID de pista del motor de pagos predeterminado.
Ejemplo de flujo de práctica de la industria
CIT inicial:
order.id= "OD12345"transaction.id= "TRAN 1"agreement.id == "AGR 1"sourceOfFunds.type=CARDoSCHEME_TOKEN- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=INTERNETsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
MIT de práctica de la industria posterior, presentada como nuevo pedido, debido a un cargo retrasado:
order.id="OD45678"transaction.id= "TRAN 2"agreement.id == "AGR 1"sourceOfFunds.type=CARDoSCHEME_TOKEN- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEreferenceOrderId="OD12345"
Pagos de reenvío iniciados por el negocio
Puede volver a enviar los pagos fallidos para su procesamiento al motor de pagos si el pagador ha aceptado que usted almacene sus detalles de pago para uso futuro y la respuesta del emisor al pago fallido no le prohíbe volver a intentarlo más tarde.
En la solicitud de reenvío del MIT, debe proporcionar los siguientes campos:
order.idEn caso de un nuevo envío de una MIT, utilice el mismo ID de pedido que en la primera MIT, pero un nuevo transaction.id, ya que el motor de pagos no permite ID de transacción duplicados dentro del mismo pedido.
transaction.resubmission = "true"Indicación de que este MIT es un nuevo envío para una autorización anterior fallida.
referenceOrderIdID de pedido de la CIT anterior. El motor de pagos utiliza este campo para buscar el ID de pista de la CIT anterior.
- Si la CIT anterior se realizó fuera del motor de pagos, en su lugar debe proporcionar:
transaction.acquirer.traceidID de pista. Este campo contiene el
authorizationResponse.transactionIdentifierde la respuesta de la CIT inicial de la serie. Este campo solo es necesario si el ID del pedido de referencia no está presente. - Si proporciona el ID del acuerdo y no proporciona el ID del pedido de referencia o el ID de pista en las tarjetas Mastercard procesadas, el motor de pagos proporcionará un ID de pista del motor de pagos predeterminado.
Ejemplo de flujo de reenvío
CIT inicial:
order.id= "OD12345"transaction.id= "TRAN 1"agreement.id= "AGR 1"sourceOfFunds.type=CARDoSCHEME_TOKEN- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=INTERNETsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
Primera MIT, enviada como un nuevo pedido, como pago de práctica de la industria debido a un cargo retrasado:
order.id="OD5678"transaction.id= "TRAN 2"sourceOfFunds.type=CARDoSCHEME_TOKEN- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEreferenceOrderId="OD12345"
Después de que la primera MIT falla debido a fondos insuficientes, se envía una segunda MIT como reenvío (mismo pedido):
order.id="OD5678"transaction.id= "TRAN 3"sourceOfFunds.type=CARDoSCHEME_TOKEN- campos de
sourceOfFunds.provided.card.*osourceOfFunds.token transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEtransaction.resubmission="true"
Preguntas frecuentes
¿Cómo le indico al motor de pagos cómo se manejan los datos de pago?
Para cumplir con los estándares del esquema de tarjetas para el procesamiento de CIT y MIT, debe utilizar el campo sourceOfFunds.provided.card.storedOnFile para indicar al motor de pagos si los detalles de pago están almacenados, no almacenados o si tiene intención de almacenarlos.
Para la CIT inicial:
- Si se trata de un pago único y no tiene intención de almacenar los detalles del pago, omita el campo
sourceOfFunds.provided.card.storedOnFileen la solicitud. -
Si esta es la primera vez que el pagador hace negocios con usted y sus detalles de pago no se han almacenado anteriormente, pero ahora tiene la intención de almacenarlos para uso futuro, configure
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED. Esto indica al motor de pagos que el pagador aceptó que usted almacene sus detalles de pago. Debe establecer este valor independientemente de:- Cómo almacena los detalles de pago: en su propia aplicación o sitio web (requiere que sea compatible con PCI), o usando tokenización del motor de pagos o de la red.
- Si almacena los detalles de pago antes o después de enviar la transacción al motor de pagos.
Si está utilizando Hosted Checkout o Hosted Session, puede almacenar los detalles de pago mediante la tokenización del motor de pagos o de la red después de que se haya realizado la CIT inicial y el pagador haya proporcionado sus detalles de pago al motor de pagos. Utilice la operación CREATE OR UPDATE TOKEN con el ID de sesión correspondiente.
Si está utilizando Direct Payment o Hosted Batch, puede almacenar los detalles antes o después de que se complete la CIT inicial.
- Si el pagador es un cliente recurrente y usted ha almacenado sus datos de pago anteriormente para un pedido diferente, no es necesario que vuelva a almacenar sus datos de pago. Sin embargo, si utiliza la nueva CIT para crear un acuerdo con el pagador para futuras MIT relacionadas con esta CIT, establezca
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED. Esto le indica al motor de pagos que utilizará estos detalles para futuras transacciones MIT.
Para pagos posteriores, configure sourceOfFunds.provided.card.storedOnFile=STORED para indicar que la credencial registrada se utiliza en el pago. Esto también se aplica en situaciones en las que el pagador regresa y sus datos de pago almacenados se utilizan para una nueva CIT que no requiere un nuevo acuerdo para futuras MIT.
¿Qué pasa si no tengo un ID de acuerdo?
Si no tiene un identificador único para su acuerdo con el pagador, puede:
- Genere un ID de acuerdo para fines de interacción con el motor de pagos. Luego, debe almacenarlo y enviarlo al motor de pagos para todos los pagos de la serie, incluida la CIT.
- Utilice un identificador existente (que ya esté almacenado en el sistema), por ejemplo, el ID de pedido para el primer pago de la serie.
Utilice siempre un ID de acuerdo si es posible, ya que es una indicación de valor única entre usted y el pagador. Por ejemplo, si el pagador necesita renovar su póliza de seguro, el ID del acuerdo puede ser el número de póliza.
En algunas situaciones, es posible que no tenga acceso al ID del acuerdo original. Por ejemplo:
- El acuerdo se alcanzó hace mucho tiempo y los detalles no quedaron registrados.
- Usted desconoce el ID del acuerdo inicial o se realizó en otro motor de pagos.
En estos casos, no puede generar un nuevo ID de acuerdo, sino que debe utilizar un ID de pedido de referencia o un ID de seguimiento.
El ID del pedido de referencia refleja el último pedido dentro de la serie de transacciones. Por ejemplo, si la serie de transacciones consta de un CIT inicial y 2 MIT posteriores:
- La CIT inicial tiene el ID de pedido = 1
- La primera MIT tiene el ID de pedido = 2 y utiliza el ID de pedido de referencia = 1 (ya que se refiere a la CIT inicial)
- El segundo MIT tiene el ID de pedido = 3 y utiliza el ID de pedido de referencia = 2 (ya que se refiere al primer MIT, que es el último ID de pedido de la serie)
El ID de seguimiento (también llamado ID de transacción del esquema) es un identificador único que todos los esquemas emiten para cada transacción procesada a través de ellos. El ID de seguimiento se utiliza para identificar transacciones asociadas, por ejemplo:
- Transacción CAPTURE posterior
- Reversión de una transacción
- Transacción REFUND AUTHORIZATION vinculada
- Transacción posterior en una serie de pagos recurrentes, a plazos o no programados
- Transacción AUTHORIZATION para ser actualizada
Los esquemas utilizan diferentes métodos para generar esta identificación:
- Mastercard genera un ID que combina:
- Código de red financiera de 3 dígitos
- Número de referencia de Banknet (AN6)
- Fecha de transacción (MMDD)
- VISA genera un ID que es único para cada transacción original.
- Amex genera un ID que es único para cada transacción original.
¿Debo enviar un pago a la hora de establecer el acuerdo de pago?
No. Si no tiene intención de cobrar al pagador al establecer un acuerdo de pago con él, por ejemplo, en el caso de una suscripción a una revista donde el primer pago está programado en 30 días, debe enviar una solicitud VERIFY con los detalles del acuerdo:
agreement.idagreement.type
La transacción Verify se convierte en el primer CIT de la serie. Para cualquier pago posterior, use el agreement.id para vincular pagos en la serie.
Si el pagador se ha autenticado en el motor de pagos mediante autenticación 3DS, puede proporcionar el authentication.transactionId a partir del resultado de la autenticación del motor de pagos en la solicitud VERIFY para vincular la autenticación al acuerdo de pago. Para transacciones autenticadas externamente, consulte las preguntas frecuentes en autenticación 3DS.
¿Qué pasa si cambian los detalles de pago de un acuerdo?
Los detalles de pago de un acuerdo pueden cambiar si, por ejemplo:
- El pagador perdió su tarjeta y se le emitió una nueva.
- El pagador cambió de banco.
- La tarjeta no tenía fondos suficientes y el pagador proporcionó otros detalles de pago
Si los detalles de la tarjeta han cambiado (excepto en caso de reemisión de una tarjeta vencida y tokens de red), debe realizar un CIT utilizando el ID del acuerdo original para actualizar los detalles de pago o el token del motor de pagos antes de realizar cualquier MIT con el nuevo número de tarjeta. Dependiendo de su modelo de negocio, también puede decidir crear un nuevo acuerdo con el pagador.
Si está utilizando la tokenización de red, los sistemas de tarjetas pueden actualizar automáticamente el número de tarjeta asociado al token de red en el motor de pagos.