Resumen general

La API de Chargeback es un canal de comunicación entre la plataforma y los comerciantes que tienen disputas asignadas. Permite a los comerciantes:

  • listar las disputas asignadas a ellos
  • ver los detalles de la disputa
  • visualizar el historial de disputas y el rastro de auditoría (audit trail)
  • impugnar (presentar un recurso) o aceptar una disputa
  • enviar documentos de respaldo (evidencias)
  • descargar o listar documentos enviados previamente

La API está diseñada para intercambios seguros y auditables, y admite paginación, filtros y control de acceso basado en roles.

Actores y permisos
  • Comerciante: puede acceder a las disputas 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 equipos de cumplimiento (opcional).
Conceptos y enumeraciones comunes
Estado de la disputa
  • Disputa ganada = El comerciante ganó la disputa y cualquier débito de contracargo es revertido.
  • Disputa perdida = El comerciante perdió la disputa y el valor del contracargo será debitado del comerciante.
  • Disputa parcialmente ganada = El comerciante perdió la disputa, pero el valor del contracargo no será debitado en su totalidad.
  • Requiere respuesta = El comerciante debe enviar el documento o aceptar el contracargo.
  • En análisis = La respuesta está siendo validada por Getnet Network.
Estado de comerciante
  • documentation_reproved = El equipo de PagoNXT determinó que los documentos enviados no pueden ser utilizados como evidencia.
  • merchant_notified = El comerciante ha sido notificado de que se requiere una respuesta.
  • verification_required = No hay problemas pendientes del lado del comerciante, ya que se han proporcionado los documentos necesarios.
  • chargeback_accepted = No hay problemas pendientes del lado del comerciante, ya que el contracargo ha sido aceptado.
Ciclos
  • retrieval_request = La solicitud de recuperación ocurre cuando el emisor de la tarjeta solicita información adicional sobre la transacción antes de iniciar un contracargo.
  • retrieval_fulfillment = La respuesta del comerciante a la solicitud de recuperación. Incluye todos los documentos y notas enviados para satisfacer la consulta del emisor.
  • first_chargeback = Un primer contracargo (también conocido como contracargo inicial) ocurre cuando el emisor o el titular de la tarjeta disputa una transacción y los fondos pueden ser debitados del comerciante.
  • second_representment = La segunda presentación (también llamada representación) es la respuesta formal del comerciante al primer contracargo. El comerciante envía las evidencias al adquirente, que las remite al emisor para su análisis. Si se acepta, el contracargo será revertido; si se rechaza, puede avanzar a la prearbitraje.
  • pre_arbitration = Ocurre cuando el emisor no está de acuerdo con la segunda presentación del comerciante. Es la oportunidad del emisor de reabrir la disputa antes de enviarla a la arbitraje de la red de tarjetas.
  • arbitration_chargeback = Etapa final del proceso de disputa, en la que la red de tarjetas toma una decisión. En este punto, ambas partes han presentado evidencias y las reglas de la red favorecen al emisor o al comerciante. Esta decisión es final e irreversible.
Credenciales de acceso
Para obtener las credenciales de la API, póngase en contacto con su gerente de cuentas para recibir orientación. Su gerente le proporcionará las instrucciones necesarias y lo ayudará en el proceso de integración y generación de credenciales, incluyendo su client_id y client_secret.
Autenticación y autorización
La API de Chargeback utiliza OAuth 2.0 para la autenticación y autorización, junto con tokens bearer para el acceso a los recursos.
Flujo
  1. El comerciante (o el cliente de la plataforma) se autentica mediante OAuth 2.0: flujo de credenciales de cliente.
  2. La plataforma emite un token de acceso bearer con un alcance (scope) específico.
  3. Cada solicitud posterior a la API debe incluir el encabezado de autorización (header) con el token.
  • Todos los tokens son de corta duración y deben renovarse mediante el flujo OAuth 2.0. Los refresh tokens son compatibles cuando corresponde.
Ejemplo de flujo de autenticación
  1. Obtenga un token de acceso desde /oauth2/access_token.
  2. Utilice el token en todas las llamadas a la API posteriores como Authorization: Bearer <access_token>.
  3. 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 scopes de OAuth2 y la propiedad del comerciante.
  • Los archivos de evidencias se almacenan cifrados en reposo (at rest).
  • Todas las acciones son registradas para auditoría.
  • Cumplimiento con los estándares PCI-DSS, GDPR y LGPD.