{"section":"tutorials","requestedLocale":"es","requestedSlug":"payment-provider-protocol","locale":"es","slug":"payment-provider-protocol","path":"docs/es/tutorials/pagos/visión-de-conjunto-de-pagos/payment-provider-protocol.md","branch":"main","content":"Payment Provider Protocol es el protocolo de integración entre VTEX y otras empresas que procesan pagos.\n\nPor medio de él, VTEX ofrece un contrato público disponible para todos los proveedores que desean integrarse a nuestra plataforma. Así, los proveedores obtienen mayor autonomía en relación a la integración.\n\nEl protocolo cuenta con los siguientes recursos:\n\n- Proceso de homologación online.\n- Soporte de pre-autorización (captura de 2 pasos).\n- Mecanismo de intento de autorización de pago.\n- Soporte para flujo de redireccionamiento de pago (3P).\n- Soporte al protocolo OAuth para la autenticación.\n\nMás información sobre el flujo de pago del protocolo se puede encontrar en la sección [Flujo del protocolo de pago](/es/docs/tutorials/payment-provider-protocol#flujo-del-protocolo-de-pago).\nUsted puede encontrar referencias a la API del protocolo [aquí](https://developers.vtex.com/docs/guides/payment-provider-protocol-api-overview).\n\n## Conceptos\n__Provider:__ sistema de pago, gateway o proveedor que procesa pagos.\n\n__Payment Provider Protocol:__ protocolo de integración desarrollado por VTEX.\n\n__Conector:__ nombre del proveedor asociado de integración con VTEX.\n\n__Oauth:__ protocolo de autorización para API web diseñado para permitir que las aplicaciones de cliente tengan acceso a un recurso protegido en nombre de un usuario.\n\n__Adquirente:__ empresa especializada en procesar pagos. Se encarga de transferir a la cuenta de tu tienda los valores cobrados al cliente por el banco emisor.\n\n## Requisitos previos\n\n### Firma de un contrato de asociación comercial para servicios financieros\n\nLa implementación, publicación y actualización de un conector de pagos en VTEX requiere la celebración un contrato de asociación específico para servicios financieros que cubra los detalles del tema y las regulaciones dentro de la plataforma. Si aún no tienes un contrato de colaboración, pero estás interesado en convertirte en proveedor de pagos, ponte en contacto con nuestro equipo a través de nuestro [sitio web](https://vtex.com/ar-es/partner).\n\n### Acceso a un entorno VTEX\n\nPara publicar un conector, necesitas disponer de un entorno VTEX, que solo puedes obtener tras firmar un acuerdo de asociación para servicios financieros. El entorno VTEX es necesario para que puedas publicar, homologar, actualizar y acceder a nuestro soporte para el desarrollo y mantenimiento del conector.\n\nSi el _partner_ es un SI (Service Implementer) que desarrolla integraciones para clientes u otros proveedores de pagos, la cuenta VTEX utilizada debe ser la del proveedor principal del medio de pago y no la de la agencia contratada.\n\n### Requisitos de los medios de pago\n#### Proveedores de pagos con tarjetas de crédito, débito y cobranded (soluciones sin redirect) \n\nPara ser un proveedor VTEX integrado, debes usar una de las siguientes soluciones:\n\n- La infraestructura donde estará el conector debe contar con un certificado PCI-DSS firmado por un asesor de seguridad calificado o QSA (Qualified Security Assessor, por sus siglas en inglés). Más información sobre el [Consejo de normas de seguridad de PCI](https://www.pcisecuritystandards.org/).\n- Si no tienes el certificado, puedes implementar al proveedor usando el [Secure Proxy](https://developers.vtex.com/docs/guides/payments-integration-secure-proxy).\n\nSi el proveedor se ha certificado o ha iniciado el proceso de certificación, puede ponerse en contacto con el equipo comercial de VTEX para iniciar la integración.\n\nEl proveedor debe enviar el [AOC](https://www.pcisecuritystandards.org/document_library) (Attestation of Compliance for Onsite Assessments - Service Provider Version) completamente rellenado a VTEX, observando los siguientes puntos:\n\n- __Nombre de la empresa__: el campo “URL” (Parte 1a.) debe ser el mismo que el de la empresa que solicita el procedimiento de integración. Si se completa con otro nombre (ejemplo: empresa adquirida por otra), será necesario enviar documentación adicional que acredite la relación entre las empresas, y que la URL del servicio del proveedor fue evaluada por la PCI DSS.\n- __Firma__: documento firmado por el representante de la empresa y por el QSA.\n- __Fecha de vencimiento__: la validez del AOC es de 1 año después de la fecha de firma. No debe reenviarse a VTEX, el AOC emitido hace más de 11 meses, es decir, con menos de 30 días para la fecha de vencimiento.\n\n> ⚠️ Siempre que sea necesario actualizar un conector que procese pagos con tarjetas de crédito, débito o cobranded, será obligatorio realizar nuevamente el proceso de [homologación](https://developers.vtex.com/docs/guides/payments-integration-payment-provider-homologation) (apertura de un ticket y envío del AOC), excepto cuando el conector cumpla simultáneamente las condiciones descritas en este [artículo](https://developers.vtex.com/docs/guides/payments-integration-payment-provider-homologation#when-is-payment-provider-homologation-not-required).\n\n> ❗ Los documentos SAQ (Self-Assessment Questionnaire) y AOC (Attestation of Compliance for Onsite Assessments – Merchants Version) no se aceptan en el proceso de integración de VTEX.\n
\n\n#### Proveedores de pagos offline o tarjeta private label (o tarjetas en general), pero que implican soluciones con redirect\n\nPara estes tipo de proveedores, VTEX no requiere comprobación de certificación PCI DSS. Sólo tienes que ponerse en contacto con el equipo comercial de VTEX para iniciar la integración.\n\n## Primeros pasos\nA continuación, vamos a presentar paso a paso las informaciones referentes a la integración de pagos con VTEX.\n\n### 1. Implementación del protocolo\nAntes de configurar el ambiente VTEX, el proveedor debe implementar el servicio de back-end necesario para recibir y procesar los pagos (API). Más información sobre el flujo de pago del protocolo se puede encontrar en la sección [Flujo del protocolo de pago](/es/docs/tutorials/payment-provider-protocol#flujo-del-protocolo-de-pago). Usted puede encontrar referencias a la API del protocolo [aquí](https://developers.vtex.com/docs/guides/payment-provider-protocol-api-overview).\n\n### 2. Casos de uso específicos\nHay casos en que se pueden crear conectores para atender alguna solución específica. A continuación, se presentan las referencias de nuestra documentación que contienen información sobre estos casos:\n\n- [Payment Provider Framework (PPF)](https://developers.vtex.com/docs/guides/payments-integration-payment-provider-framework): es una solución para la implementación de conectores a través de VTEX IO con base en un _boilerplate_. El _boilerplate_ ya viene con una gran parte del trabajo realizado, incluyendo los _endpoints_ del protocolo. La utilización de VTEX IO también acelera el proceso de desarrollo y pruebas de la tienda.\n\n- [Payment Provider Protocol (PPP) aplicado a los pagos con POS - VTEX Sales App](https://developers.vtex.com/docs/guides/payments-integration-ppp-applied-to-pos): es la aplicación del PPP a pagos en tiendas físicas utilizando un terminal de pago (POS). Se puede utilizar con tarjetas de crédito o débito. El flujo del pago se inicia con una compra realizada en [inStore](/es/docs/tracks/que-es-vtex-sales-app), después de lo cual se establece la comunicación con el POS, donde el cliente inserta la tarjeta.\n\n### 3. Homologación de Payment Provider\n\nDespués de recibir los datos de acceso e implementar el backend, el proveedor debe instalar la aplicación Payment Provider Test Suite para acceder a la herramienta de pruebas. La instalación se realiza a través de la VTEX App Store.\n\n\n\n> ⚠️ Para completar el proceso de homologación, se debe implementar una lógica específica para abordar los requisitos de la prueba. En los requests enviados a Test Suite, utiliza el encabezado adicional `X-VTEX-API-Is-TestSuite = true` para identificarlos y enmascarar cualquier escenario requerido.
Toda comunicación con los servidores, ya sea durante el proceso de homologación o en producción, debe llevarse a cabo a través de HTTPS, que utiliza el puerto 443 de forma predeterminada. Es importante recordar que toda comunicación HTTPS debe usar exclusivamente TLS 1.2. \n\n\n\nTras la instalación, haz clic en Apps, en el panel lateral izquierdo del Admin. A continuación, selecciona la aplicación Payment Provider Test Suite para configurarla correctamente.\n\nDependiendo de la versión del Admin utilizada en la cuenta de la tienda, la aplicación estará disponible en la lista de aplicaciones. Para acceder a ella, utiliza la dirección [https://\\{\\{accountName\\}\\}.myvtex.com/admin/test-suite](about:blank)/payment-provider, sustituyendo \\{\\{accountName\\}\\} por el nombre de cuenta de tu tienda.\n\nLuego, verás un formulario que tiene tres secciones: Información de servicio, Medio de pago y Casos de prueba. Rellena los campos según las instrucciones a continuación.\n\n#### Información de servicio\n\n* **URL de servicio:** define la URL del servicio de tu proveedor. Esta URL será la dirección base del protocolo y debe seguir el formato determinado por el proveedor. Por ejemplo, si la URL del servicio es [https://example.com/](https://example.com/), la URL completa del endpoint /payments será [https://example.com/payments](https://example.com/payments).\n* **Clave de aplicación y token de aplicación:** el botón de alternancia con clave de aplicación y token de aplicación te permite escoger si se configuran estos campos o no, lo que puede facilitar las pruebas durante la etapa de desarrollo. Si no se activa esta opción, las credenciales se enviarán en los encabezados como una string vacía.\n\n> ℹ️ El gateway almacena las credenciales de las tiendas configuradas en la afiliación y las envía en los encabezados X-VTEX-API-AppKey y X-VTEX-API-AppToken. La excepción son las integraciones desarrolladas con VTEX IO, en cuyo caso, los encabezados se envían como x-provider-api-appKey y x-provider-api-appToken. Si estás desarrollando usando [Payment Provider Framework (IO)](https://developers.vtex.com/vtex-rest-api/docs/payments-integration-payment-provider-framework), esto lo define la opción usesProviderHeadersName. Consulta los ajustes disponibles [aquí](https://developers.vtex.com/vtex-rest-api/docs/payments-integration-payment-provider-framework#available-configurable-options). \n\n#### Medio de pago\n\nDespués de rellenar URL de servicio, Test Suite validará el [Endpoint Manifest](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#get-/manifest) y verificará los medios de pago declarados, que aparecerán en este campo. Selecciona los medios de pago en los que deseas ejecutar las pruebas.\n\n#### Casos de prueba\n\nEn esta sección, debes seleccionar los casos que deseas probar. Si estás probando un medio de tarjeta de crédito, tu integración debe pasar los casos Aprobado, Denegado, Cancelación, Aprobado asíncrono y Denegado asíncrono. Los medios de pago con [redirección](https://developers.vtex.com/docs/guides/payments-integration-purchase-flows#redirect) solo necesitan el Flujo de redirección.\n\n\n\n### 4. Pruebas\nCuando haces clic en el botón `Ejecutar prueba`, Test Suite llama la URL de servicio proporcionada y ejecuta los casos de prueba seleccionados. Las pruebas son:\n\n* **Flujo aprobado:** esta prueba se divide en tres etapas. En la primera, se envía un request [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) a \\{\\{ServiceURL\\}\\}/payments y se espera el status aprobado como respuesta. En la segunda, se envía un request [Settle Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments/-paymentId-/settlements) a \\{\\{ServiceURL\\}\\}/payments/\\{paymentId\\}/settlements y se espera la respuesta con el settleId rellenado. Y en la última, se envía un request [Refund Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments/-paymentId-/refunds) a \\{\\{ServiceURL\\}\\}/payments/\\{paymentId\\}/refunds y se espera una respuesta con refundId rellenado.\n* **Flujo denegado:** en esta prueba, se envía un request [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) a \\{\\{ServiceURL\\}\\}/payments y se espera el status denegado como respuesta.\n* **Flujo de cancelación:** para esta prueba, primero se necesita el status approved como respuesta del request [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) de \\{\\{ServiceURL\\}\\}/payments. Luego, se envía un request [Cancel Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments/-paymentId-/cancellations) a \\{\\{ServiceURL\\}\\}/payments/\\{paymentId\\}/cancellations y se espera una respuesta con el status cancelado.\n* **Flujo aprobado asíncrono:** esta prueba se divide en dos pasos. Primero, se envía un request [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) a \\{\\{ServiceURL\\}\\}/payments y se espera el status undefined como respuesta. Después de 15 segundos, se espera otra respuesta en el mismo formato mediante un POST de la URL enviada en el campo callbackUrl y con el status approved. Con la integración en producción, esta última llamada realizada por callbackUrl se autentica con las claves de entorno del partner: vtex-app-key y vtex-app-token. Para más información sobre el flujo de callback consulta la sección [Autorización del pago](#autorizacion-de-pago).\n* **Flujo denegado asíncrono:** como la anterior, esta prueba se divide en dos pasos. Primero, se envía un request [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) a \\{\\{ServiceURL\\}\\}/payments y se espera el status undefined como respuesta. Después de 15 segundos, se espera otra respuesta en el mismo formato mediante un POST de la URL enviada en el campo callbackUrl y con el status denied. Con la integración producción, esta última llamada realizada por callbackUrl se autentica con las claves de entorno del partner: vtex-app-key y vtex-app-token. Para más información sobre el flujo de callback consulta la sección [Autorización del pago](#autorizacion-de-pago).\n* **Flujo de boleto:** en esta prueba, se envía un request[ Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) a \\{\\{ServiceURL\\}\\}/payments y se espera una respuesta con status undefined y el campo `bankIssueInvoiceUrl` rellenado con la URL del ticket. Después de 15 segundos, se espera otra respuesta en el mismo formato mediante un POST de la URL enviada en el campo callbackUrl y con el status approved. Con la integración en producción, esta última llamada realizada por callbackUrl se autentica con las claves de entorno del partner: vtex-app-key y vtex-app-token. Para más información sobre el flujo de callback consulta la sección [Autorización del pago](#autorizacion-de-pago).\n* **Flujo de redirección:** esta prueba se divide en dos pasos. Primero, se envía un request [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) a \\{\\{ServiceURL\\}\\}/payments y se espera una respuesta con status undefined y el campo redirectUrl rellenado con la URL que se utilizará para redirigir al cliente. Después de 15 segundos, se espera otra respuesta en el mismo formato mediante un POST de la URL enviada en el campo callbackUrl y con el status approved. Con la integración en producción, esta última llamada realizada por callbackUrl se autentica con las claves de entorno del partner: vtex-app-key y vtex-app-token. Para más información sobre el flujo de callback consulta la sección [Autorización del pago](#autorizacion-de-pago). El conector que utilizará redirección no tiene que pasar todas las pruebas de Test Suite, solo la prueba de Redirección.\n\n> ⚠️ En el caso de las tarjetas de crédito, las pruebas obligatorias son: Autorizar, Denegado, Cancelar, Aprobado asíncrono y Denegado asíncrono.\n\nPara identificar cómo responder a cada una de las pruebas con tarjetas de crédito, utiliza los siguientes números específicos:\n\n| Número de tarjeta | Status de la respuesta |\n| ----------------- | ------------------------------------------ |\n| 4444333322221111 | __approved__ |\n| 4444333322221112 | __denied__ |\n| 4222222222222224 | __undefined__, `callbackUrl` con status __approved__ |\n| 4222222222222225 | __undefined__, `callbackUrl` con status __denied__ |\n\n### 5. Resultados\n\nDespués de ejecutar las pruebas, el sistema mostrará el Informe de prueba que presenta los resultados detallados de cada caso de prueba. De este modo, tendrás más visibilidad sobre lo que debes ajustar si se produce un error.\n\n\n\nPara ver los mensajes transmitidos entre Test Suite y la implementación de tu proveedor de pagos, haz clic en el botón Inspeccionar logs. Se abrirá una ventana modal que muestra la lista de mensajes transmitidos y la carga de cada request y respuesta. El botón situado en la esquina superior derecha de la sección de código facilita la copia del código al portapapeles.\n\n\n\n## Flujo del protocolo de pago\nAquí vamos a explicar el flujo de pago integrado en detalle. La siguiente imagen muestra todo el flujo, mostrando VTEX Payments y las responsabilidades de su proveedor.\n\nTodo comienza con la solicitud de un nuevo pago, después de la creación de un nuevo pedido. VTEX crea una nueva representación del pago y avanza para el procesamiento de los pagos.\n\n\n\n> ℹ️ El período predeterminado de 7 días para reintentos (retries) de pago asíncronos solo se aplica cuando el usuario no especifica un valor en el campo `delayToCancel` del endpoint [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments) o al enviar la URL de devolución de llamada.\n\n> ⚠️ El valor máximo permitido para el campo `delayToCancel` es 30 días (2592000 segundos). Sin embargo, en los pagos realizados a través de PIX (medio de pago instantáneo brasileño), los valores deben fijarse entre 15 e 60 minutos (900 y 3600 segundos). \n\n### Autorización de pago\nEn este punto, VTEX llama al endpoint __*/payments*__ y envía un payload con los datos de pago para su proveedor. El proveedor debe procesar estos datos y enviar la respuesta, que debe contener uno de los valores de status: __approved__, __denied__ o __undefined__.\n\nEl status __undefined__ representa el estado en el que el proveedor no pudo terminar de procesar el pago. Esto puede deberse a una larga ejecución de procesamiento o a algún procesamiento asincrónico.\n\nEn cualquiera de los casos, una vez que termine el procesamiento y el proveedor tenga un status final (__approved__ or __denied__), deberá hacer una llamada a nuestro `callbackUrl`. Enviamos el `callbackUrl` en el cuerpo del _request_ __/payments__. Hay dos flujos posibles al usar `callbackUrl` dependiendo de si tu integración está hospedada en la infraestructura del partner o en VTEX IO:\n\n- __Sin VTEX IO:__ El `callbackUrl` contiene un endpoint de callback para que el proveedor notifique al gateway el status actualizado.\n- __Con VTEX IO:__ El `callbackUrl` contiene un endpoint de reintento (retry). Cuando el proveedor utiliza este endpoint para llamar al gateway, se produce una nueva solicitud de Create Payment (/payments) del gateway al proveedor, y el gateway recibe el status de pago actualizado en respuesta a esta solicitud.\n\nEl flujo completo con status undefined y uso de notificación se puede ver a continuación:\n\n\n\n1. La autorización del pago se inicia cuando el _gateway_ hace una llamada al endpoint Create Payment (__/payment__) para el proveedor. El campo `callbackUrl` se envía dentro del cuerpo del _request_ y contiene la URL para hacer la notificación.\n2. El pago se produce de forma asíncrona (no genera el status definitivo cuando se inicia la transacción). A continuación, el _gateway_ recibe la respuesta con status __undefined__ y espera a que se complete el procesamiento del pago. Más adelante, el pago se completará y el _gateway_ recibirá el status definitivo (__approved__ o __denied__).\n3. Cuando se procesa el pago, el adquirente activa un _webhook_ al proveedor con el nuevo status.\n4. El proveedor, al recibir el pedido por _webhook_, hace una llamada al _endpoint_ de notificación y devuelve el status actualizado al _gateway_.\n\nEl flujo completo con status __undefined__ y uso del __retry__ se puede ver a continuación:\n\n\n\n1. La autorización del pago se inicia cuando el _gateway_ hace una llamada al _endpoint_ Create Payment (__/payment__) para el proveedor. El campo `callbackUrl` se envía dentro del cuerpo del _request_ y contiene la URL del endpoint __retry__.\n2. El pago se produce de forma asíncrona (no genera el status definitivo cuando se inicia la transacción). A continuación, el _gateway_ recibe la respuesta con status __undefined__ y espera a que se complete el procesamiento del pago. Más adelante, el pago se completará y el _gateway_ recibirá el status definitivo (__approved__ o __denied__).\n3. Cuando se procesa el pago, el adquirente activa un _webhook_ al proveedor con el nuevo status.\n4. El proveedor, al recibir el pedido por webhook, hace una llamada al _endpoint_ __retry__ para el _gateway_, indicándo le que llame de nuevo al _endpoint_ __/payment__. El __retry__ no requiere ninguna carga.\n5. Después de recibir el __retry__, el _gateway_ llama de nuevo al _endpoint_ __/payment__. Finalmente, el _gateway_ recibe la respuesta del proveedor con el nuevo status (__approved__ o __denied__).\n\n## Callback URL\n\nEl campo `callbackUrl` contiene una URL que el proveedor de pagos utiliza para realizar un _callback_ y notificar a nuestro gateway el status final del pago: `aprobado` o `denegado`.\n\nEsta URL tiene algunos parámetros de consulta, incluyendo `X-VTEX signature`. Este parámetro es obligatorio y contiene un _token_ de firma para indicar que el request ha sido generado por VTEX como una medida de seguridad. El token de firma tiene como máximo 32 caracteres. Puedes ver un ejemplo de una URL de _callback_ con el token de firma a continuación:\n\n```\nhttps://gatewayqa.vtexpayments.com.br/api/pvt/payment-provider/transactions/8FB0F111111122222333344449984ACB/payments/A2A9A25B11111111222222333327883C/callback?accountName=teampaymentsintegrations&X-VTEX-signature=R123456789aBcDeFGHij1234567890tk\n```\n\nEn la [página de Transacciones del Admin](/es/docs/tutorials/como-visualizar-detalle-del-pedido), el token de firma se muestra enmascarado por razones de seguridad, como en este ejemplo: `X-VTEX-signature=Rj******tk`.\n\nVea a continuación, um ejemplo de payload enviada junto con la callback URL:\n\n```json\n{\"paymentId\":\"8B3BA2F4352545A8B1C5A215F356A01C\",\"status\":\"approved\",\"authorizationId\":\"184520\",\"nsu\":\"21705348\",\"tid\":\"21705348\",\"acquirer\":\"pagarme\",\"code\":\"0000\",\"message\":\"Transação aprovada com sucesso\",\"delayToAutoSettle\":1200, \"delayToAutoSettleAfterAntifraud\":1200, \"delayToCancel\":86400,\"cardBrand\":\"Mastercard\",\"firstDigits\":\"534696\",\"lastDigits\":\"6921\",\"maxValue\":16.6}\n```\n\n> ℹ️ Los valores de los parámetros enviados en el payload de callback reemplazan los valores originales informados en la llamada de [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol#post-/payments).\n\n> ⚠️ Si los parámetros de tiempo de espera (*delayToAutoSettle* e *delayToAutoSettleAfterAntifraud*) no se envían con la URL de devolución de llamada, los valores se establecerán automáticamente en 24 horas.\n\nAl realizar el request de _callback_, recomendamos que los proveedores de pago utilicen la URL de _callback_ exactamente como la recibieron, lo que garantiza que se incluyan todos los parámetros.\n\nAl llamar a CallbackURL, su proveedor debe enviar en el request los headers *X-VTEX-API-AppKey* y *X-VTEX-API-AppToken*. Más información sobre esto en la [sección de credenciales VTEX](/es/docs/tutorials/payment-provider-protocol#credenciales-vtex).\n\n> ❗ Además de CallbackURL, si el status es **undefined**, VTEX intentará de nuevo llamar al endpoint de la autorización de pago. Si el status devuelto en estas llamadas permanece como **undefined**, las llamadas continuarán por 7 días. Por lo tanto, **es importante que su proveedor esté preparado para recibir la misma autorización de pago varias veces**.\n\nUna vez que el pago ha sido procesado por su proveedor, de forma directa o asincrónica, movemos la transacción de pago dentro de VTEX al status *autorizado* o *cancelado*, de acuerdo con el status de la respuesta del procesamiento.\n\nMás referencias a la API de autorización [aquí](https://developers.vtex.com/docs/guides/payment-provider-protocol-api-overview).\n\n### Reembolso/Cancelación\nDespués de la primera llamada a la autorización de pago, la tienda puede Después de la primera llamada para la autorización de pago, la tienda puede cancelar el pedido en cualquier momento. En el momento de la cancelación, pueden ocurrir las siguientes situaciones:\n\n1. __La transacción de pago ya ha sido liquidada__: la solicitud de cancelación resultará en una llamada de reembolso al endpoint del proveedor _/payments/\\{id\\}/refunds_, donde _\\{id\\}_ representa el ID de pago en VTEX. \n2. __La transacción de pago aún no se ha liquidado__: llamaremos al endpoint del proveedor _/payments/\\{id\\}/cancellations_, donde _\\{id\\}_ es el ID de pago en VTEX. Si existe alguna dificultad para procesar la cancelación automática, se enviará un correo electrónico al comerciante para que pueda cancelarla manualmente.\n\nEl Payment Provider Protocol también permite reembolsos parciales. Por ejemplo, si después de completar una compra por valor de USD 1,000, es necesario reembolsar al cliente por valor de USD 300, son posibles dos escenarios:\n\n1. __El pago ya ha sido liquidado__: se realizará un reembolso parcial de USD 300 al cliente. El valor restante (USD 700) queda a disposición del comerciante.\n2. __El pago aún no ha sido liquidado__: se hará al comerciante una cancelación de captura por el valor de USD 300 y una aprobación de liquidación parcial por el valor de USD 700. \n\nMás información acerca de la API de cancelación y reembolso [aquí](https://developers.vtex.com/docs/guides/payment-provider-protocol-api-overview).\n\n### Liquidación\nSi la transacción de pago está autorizada en VTEX Payments, puede recibir solicitudes de liquidación. Cuando recibimos una solicitud de liquidación, llamamos al endpoint __/payments/\\{id\\}/settlements__ del proveedor, donde *\\{id\\}* es el ID de pago en VTEX.\n\nCuando el proveedor recibe una solicitud de liquidación, debe liquidar el pago y responder con información de liquidación. Si esta llamada falla, hacemos algunas retentaciones, por hasta 1 día.\n\n> ❗ Su proveedor debe estar preparado para recibir la misma llamada de liquidación varias veces.\n\nSi la llamada de liquidación funciona bien, movemos la transacción de pago al estado *Finalizado*, y el flujo termina con éxito.\n\nMás información acerca de la API de liquidación [aquí](https://developers.vtex.com/docs/guides/payment-provider-protocol-api-overview).\n\n## Credenciales VTEX\nAl llamar a CallbackURL, usted debe especificar los headers de autenticación, que en VTEX son _X-VTEX-API-AppKey_ y _X-VTEX-API-AppToken_. Puede encontrar estas credenciales (que son únicas para su cuenta) en el módulo License Manager de VTEX.\n\nUtilice la URL `https://{{AccountName}}.myvtex.com/admin/license-manager/#/home`, sustituyendo el `{{AccountName}}` por su nombre de cuenta. Entonces, siga las instrucciones de [este tutorial](https://developers.vtex.com/docs/guides/authentication-overview) para aprender a crear appKeys y appTokens."}