Visión general
La API Chargeback es un canal de comunicación entre la plataforma y los comerciantes a los que se les han asignado las disputas. Permite a los comerciantes:
- enumerar las disputas que se les han asignado
- ver detalles de la disputa
- ver el historial de disputas y el registro de auditoría
- concurso (enviar un desafío) o aceptar una disputa
- Cargar documentos justificativos (pruebas)
- descargar o enumerar los documentos cargados anteriormente
La API está diseñada para intercambios seguros y auditables, y admite la paginación, el filtrado y el acceso basado en roles.
Actores y permisos
- Mercader - pueden acceder a las disputas que están asignadas a su cuenta de comerciante. Puede impugnar, aceptar y subir documentos
- Plataforma - uso interno: asignar disputas, cambiar estados, resolver disputas
- Auditor - acceso de solo lectura para los equipos de cumplimiento (opcional)
Conceptos y enumeraciones comunes
Estado de la disputa
- Disputa ganada = El comerciante ganó la disputa y se anula cualquier débito por contracargo
- Disputa perdida = El vendedor perdió la disputa y el importe de la devolución se debitará al vendedor
- Disputa parcialmente ganada = El vendedor perdió la disputa, pero el importe del contracargo no se debitará en su totalidad al vendedor
- Necesita respuesta = El vendedor debe enviar el documento o aceptar la devolución
- En revisión = La respuesta está siendo validada por Getnet Network
Estado de comerciante
- documentation_reproved = El personal de PagonXT determinó que los documentos cargados no pueden usarse como evidencia
- merchant_notified = Se ha notificado al vendedor que se necesita una respuesta
- verification_required = No hay asuntos pendientes por parte del vendedor, ya que se han proporcionado los documentos necesarios
- chargeback_accepted = No hay problemas pendientes por parte del vendedor, ya que se ha aceptado la devolución
Ciclos
- retrieval_request = la solicitud de recuperación se produce cuando el emisor de la tarjeta solicita información adicional sobre la transacción antes de iniciar una devolución.
- retrieval_fulfillment = La respuesta del vendedor a la solicitud de recuperación. Incluye todos los documentos y notas enviados para satisfacer la consulta del emisor
- first_chargeback = Se produce un primer contracargo (también conocido como contracargo inicial) cuando el emisor o el titular de la tarjeta impugna una transacción y los fondos se pueden debitar al comerciante
- second_representment = La segunda presentación (también denominada representación) es la respuesta formal del comerciante a la primera devolución de cargo. El comerciante presenta las pruebas al adquirente, quien las envía al emisor para que las revise. Si se acepta, el contracargo se anula; si se rechaza, se puede proceder a un arbitraje previo.
- pre_arbitration = Se produce cuando el emisor no está de acuerdo con la segunda presentación del comerciante. El emisor tiene la oportunidad de reabrir la controversia antes de derivarla al arbitraje de la red de tarjetas.
- arbitration_chargeback = fase final del proceso de disputa, en la que la red de tarjetas toma una decisión de licitación. En este punto, ambas partes han presentado pruebas y la red falla a favor del emisor o del comerciante. Esta decisión es final e irreversible
Credenciales de acceso
Para obtener las credenciales de la API, póngase en contacto con su administrador de cuentas para obtener orientación. Tu gestor de cuentas te proporcionará las instrucciones necesarias y te ayudará con el proceso de incorporación y generación de credenciales, incluidos tus client_id y client_secret.
Autenticación y autorización
La API Chargebacks usa OAuth 2.0 para la autenticación y la autorización, junto con Tokens al portador para acceder a los recursos.
Flujo
- El comerciante (o el cliente de la plataforma) se autentica mediante OAuth 2.0: flujo de credenciales de cliente
- La plataforma emite un Token de acceso al portador con un alcance específico
- Cada solicitud posterior a la API debe incluir el encabezado de autorización con el token
Todos los tokens son efímero y debe actualizarse mediante el flujo OAuth2. Los tokens de actualización son compatibles cuando corresponde
Ejemplo de flujo de autenticación
- Obtenga un token de acceso desde /oauth2/access_token
- Utilice el token en todas las llamadas a la API posteriores como Authorization: Bearer <access_token>
- El token caduca después de 1 hora. Usa el token de actualización si está disponible
Seguridad y cumplimiento
- Todos los puntos finales requieren HTTPS (TLS 1.2 O SUPERIOR).
- El acceso está controlado por Ámbitos de OAuth2 y propiedad mercantil
- Los archivos de evidencias se almacenan encriptado en reposo
- Todas las acciones son registrado para auditoría
- Cumplimiento de PCI-DSS, GDPR y LGPD estándares