Chargeback API and Dispute API Compared: Stripe, Adyen, PayPal and Chargeflow

Contracargos?
Ya no es problema tuyo.
Recupera cuatro veces más Contracargos y prevención , hasta un 90 % de las entradas, gracias a IA y a una red global de 20 000 comercios.
En resumen:
- Stripe lets you list and retrieve disputes, while the endpoint list on Adyen's Disputes API page has no read call, so Adyen case state has to be stored from webhooks.
- The deadline lives in
evidence_details.due_byon Stripe,defensePeriodEndsAton Adyen andseller_response_due_dateon PayPal, so store one absolute timestamp per case. - Adyen's documentation lists 18 days to defend a Visa chargeback (9 for US and Canada local payments), 40 for Mastercard and 14 for American Express.
- Chargeflow's Merchants API recovers your own disputes, while its Platforms API creates merchant accounts, submits disputes and generates versioned evidence PDFs.
- A generated evidence package is not a submitted response, so submit through the processor endpoint before the deadline.
A chargeback API, also called a dispute API, is a programmatic interface that lets software read dispute cases, submit or generate evidence and respond before a deadline. Stripe, Adyen and PayPal each expose a different slice of that lifecycle, so a platform that supports more than one processor needs a field mapping, not one assumption about what "the dispute API" returns.
This guide compares what the three processor APIs return and accept, as documented on 11 October 2026, then suggests a mapping from their fields to a common model and separates the two Chargeflow APIs: the merchant API and the platforms API. It stays at the API layer. For the operating model around it, see chargeback management for payment platforms.
What a chargeback API can cover
Three different things get called a chargeback API, and they answer different questions.
Identify the service before designing the integration
Three API scopes, three different responsibilities
Processor dispute API
exposes the case, accepts evidence or a defense, and lets you accept the loss. Stripe, Adyen and PayPal all offer one, and you call it with the credentials of the account that processed the payment.
Evidence-service API
turns dispute and order data into a response package. It does not submit anything to the bank. Chargeflow Evidence-as-a-Service is an example.
Merchant or managed-service API
reads cases for one merchant, enriches them with order data and uploads evidence. Chargeflow's Merchants API is an example.
Which one you need depends on whether you are a merchant or a payment service provider or platform handling disputes for many merchants.
How the Stripe, Adyen and PayPal dispute APIs compare
Stripe and PayPal let you read a dispute at any time, Adyen's Disputes API page lists no read call, and each provider puts the response deadline in a different field. Every row below comes from official documentation, checked on 11 October 2026.
| Capacidad | Stripe | Adyen | PayPal |
|---|---|---|---|
| Read a case | Dispute object. GET /v1/disputes filters by charge, payment_intent and created; limit 1 to 100 | No list or retrieve call among the endpoints on the Disputes API page. Case data arrives in dispute webhooks | GET /v1/customer/disputes and GET /v1/customer/disputes/{id} |
| Deadline field | evidence_details.due_by, a timestamp. Value 0 means the bank does not allow a response | defensePeriodEndsAt in the REQUEST_FOR_INFORMATION, NOTIFICATION_OF_CHARGEBACK and CHARGEBACK samples | seller_response_due_date |
| Status values | warning_needs_response, warning_under_review, warning_closed, needs_response, under_review, won, lost, prevented | disputeStatus inside additionalData; documented values include Undefended, Pending, Responded, Unresponded, Accepted, Caducado, Ganó and Perdido | OPEN, WAITING_FOR_BUYER_RESPONSE, WAITING_FOR_SELLER_RESPONSE, UNDER_REVIEW, RESOLVED and OTHER |
| Lifecycle stage | Inquiries carry the warning_ status prefix | Request for information, chargeback, pre-arbitration, scheme arbitration | dispute_life_cycle_stage: INQUIRY, CHARGEBACK, PRE_ARBITRATION, ARBITRATION |
| Submit evidence | POST /v1/disputes/{id} with an evidence hash. submit=false stages it | /supplyDefenseDocument per document, then /defendDispute | POST /v1/customer/disputes/{id}/provide-evidence, sent as multipart form data |
| Accept the loss | POST /v1/disputes/{id}/close. Irreversible; status becomes lost | /acceptDispute | POST /v1/customer/disputes/{id}/accept-claim |
| Events | charge.dispute.created, .updated, .closed, .funds_withdrawn, .funds_reinstated | Standard webhook with dispute event codes, including NOTIFICATION_OF_CHARGEBACK, CHARGEBACK and DISPUTE_DEFENSE_PERIOD_ENDED | CUSTOMER.DISPUTE.CREATED, .UPDATED, .RESOLVED |
| What you can do next | evidence_details.enhanced_eligibility reports Visa Compelling Evidence 3.0, Visa compliance and Mastercard compliance status | /retrieveApplicableDefenseReasons returns reason codes, document types and requirement levels | allowed_response_options on the dispute |
Sources: Stripe Dispute object, Stripe Update a dispute, Stripe event types, Adyen Disputes API, Adyen dispute notifications, PayPal Disputes v1, PayPal dispute reference, PayPal dispute definition.
The read path is the biggest structural difference. The endpoints listed on Adyen's Disputes API page cover defending and accepting, so a platform on Adyen has to persist the case from webhook payloads: pspReference identifies the dispute and originalReference identifies the disputed payment. Provider-level workflows are in the Stripe chargebacks guide, the Adyen chargebacks guide and the PayPal dispute versus chargeback guide.
The second difference is staging. Stripe can hold evidence on the dispute with submit=false and send it later, but Stripe's object reference says you may typically submit evidence only once. Adyen does not send uploaded documents to the issuer until you call /defendDispute, and you cannot add information afterwards. Model "ready to submit" and "submitted" as separate states in your own case record. Stripe also states that if evidence_details.past_due is true, delivery of the latest evidence is not guaranteed, so alert on the deadline field rather than on the status.
Evidence formats and limits differ by provider
Stripe takes text fields and file IDs, Adyen takes base64 documents, and PayPal takes typed evidence in a multipart request.
| Evidence rule | Stripe | Adyen | PayPal |
|---|---|---|---|
| Format | Text fields plus file IDs from the File Upload API, uploaded with purpose dispute_evidence | Base64 content with contentType and defenseDocumentTypeCode | evidence_type values include PROOF_OF_FULFILLMENT, PROOF_OF_REFUND and PROOF_OF_DELIVERY_SIGNATURE |
| Size limits | 150,000 characters combined across text fields; files 4.5 MB combined, and 19 pages for Mastercard | JPG and TIFF 10 MB, PDF 2 MB; Mastercard chargeback defenses 19 pages at most; request-for-information defenses 4 pages at most | Set on a separate supported file types and sizes page |
| Corrections | Typically one submission; submission_count tracks it | Delete with /deleteDisputeDefenseDocument and re-upload until you defend | Not stated in the endpoint guide reviewed |
Sources: Stripe disputes API guide, Stripe responding to disputes, Adyen Disputes API (linked above), PayPal disputes API guide.
Stripe also reports whether a dispute qualifies for Visado Compelling Evidence 3.0. Under evidence_details.enhanced_eligibility.visa_compelling_evidence_3, status is qualified, requires_action or not_qualified, and required_actions lists what is missing. The value missing_customer_identifiers means the disputed and prior undisputed transactions need at least two customer identifiers (account ID, email, shipping address, purchase IP, device ID or device fingerprint), one of them the purchase IP, device ID or fingerprint, and never device ID and fingerprint alone. Capture those fields at order time, not at dispute time.
Effective 24 October 2026, Visa's April 2026 rules let the two prior transactions come from more than one merchant, not only the disputing merchant (Visa Core Rules, 18 April 2026).
Response windows differ by network and acquirer
Per Adyen's documentation, defense windows run in calendar days from the notice of chargeback date and differ by network. These are Adyen's deadlines for its merchants, so confirm them against the current network rulebook and your acquirer.
Adyen merchant response windows · calendar days from NoC
Use the provider’s case deadline and preserve its scope
Visa, all other disputes (days)
18
Visa, US and Canada local payments opened from 21 July 2025 (days)
9
Mastercard (days)
40
American Express (days)
14
Source: Adyen dispute timeframes, Adyen's response deadlines in calendar days from the notice of chargeback date.
Windows vary by network, region and acquirer, so store the deadline the provider returns as one absolute timestamp rather than computing it from a constant. Stripe returns Unix seconds, Adyen's sample shows ISO 8601 with an offset, and Chargeflow's platform API expects an ISO 8601 due_by. Convert once at ingestion. For network clocks, see Visa chargeback time limits and the Mastercard chargeback time limit guide.
Field mapping from processor APIs to a common model
Both mappings in this section are suggestions, not provider documentation. The left column is a suggested internal model, the provider columns quote documented fields, and the last column is what Chargeflow's Platforms API requires to create a dispute record. Platforms that route across several processors need exactly this layer; see multi-processor chargeback recovery.
| Common field (suggested) | Stripe | Adyen | PayPal | Chargeflow platform dispute |
|---|---|---|---|---|
| N.º de reclamación | id | pspReference of the dispute, the same on every event | dispute_id | source_id (required) |
| Disputed payment | charge, payment_intent | originalReference | disputed_transactions | transaction (optional) |
| Motivo | reason | chargebackReasonCode | reason | reason (required) |
| Escenario | status prefix warning_ for inquiries | eventCode, such as NOTIFICATION_OF_CHARGEBACK | dispute_life_cycle_stage | stage (optional) |
| Estado | status | disputeStatus | status | status (required): needs_response, under_review, won or lost |
| Fecha límite | evidence_details.due_by | defensePeriodEndsAt | seller_response_due_date | due_by (required, ISO 8601) |
| Created | created | eventDate | create_time | created_at (required) |
Sources: provider references linked above and Chargeflow Submit Platform Disputes.
The platform record also requires account_id, amount and currency. Chargeflow documents amount as a number in the transaction currency, no greater than the transaction amount, and currency as an uppercase ISO 4217 code, while Stripe returns an integer amount and a lowercase code. The Chargeflow and Adyen pages reviewed do not say whether amounts are in minor units, so confirm the unit and convert once at ingestion. Each merchant is created first through the Platforms API accounts endpoint, which accepts an optional ext_account_id so your own merchant identifier travels with the Chargeflow account.
Chargeflow accepts seven reason values, so reasons need translating too. Adyen returns network reason codes such as 10.4 and PayPal has its own reason field, so each needs a lookup. Suggested mapping from Stripe's reasons:
| Stripe reason | Suggested Chargeflow reason |
|---|---|
fraudulent | fraud |
product_not_received | not_received |
product_unacceptable | not_as_described |
subscription_canceled | canceled_recurring_billing |
duplicate | duplicate_charge |
credit_not_processed | credit_not_processed |
Any other reason, such as general | other |
Status needs its own normalization step because the three vocabularies do not line up. The table below is a suggested mapping to the four statuses Chargeflow accepts.
| Common status (suggested) | Stripe | Adyen (documented values) | PayPal |
|---|---|---|---|
needs_response | needs_response, or warning_needs_response for an inquiry | Undefended, or Unresponded for a request for information | WAITING_FOR_SELLER_RESPONSE |
under_review | under_review, or warning_under_review | Pending or Responded | UNDER_REVIEW |
won | won | Ganó | RESOLVED, with dispute_outcome code RESOLVED_SELLER_FAVOUR |
lost | lost; also what closing a dispute sets | Perdido or Accepted | RESOLVED, with dispute_outcome code RESOLVED_BUYER_FAVOUR |
Keep the provider's raw status next to the normalized one. Pending appears at several Adyen events, so read eventCode alongside disputeStatus, and give PayPal outcome codes such as CANCELED_BY_BUYER their own rule. Support teams and reconciliation both need the original value, and the chargeback reason codes attached to a case rarely survive translation into a single internal enum.
A reference integration flow
The flow below is a general architecture. The tables above give the provider-specific calls, and your account entitlements decide which are available.
Reference architecture · provider calls and entitlements differ
From dispute event to reconciled outcome
Register for events
Register for dispute events:
charge.dispute.createdon Stripe, the Standard webhook with dispute events enabled on Adyen,CUSTOMER.DISPUTE.CREATEDon PayPal.Store the case and deadline
Store the case under your merchant identifier, with the provider's own ID and the deadline as an absolute timestamp.
Retrieve the current state
Fetch current state where a read endpoint exists (Stripe retrieve, PayPal show dispute) and fall back to the stored webhook payload where it does not (Adyen).
Match the purchase records
Match the dispute to the payment, order and fulfillment records.
Assemble or generate evidence
Assemble or generate evidence. With Chargeflow Evidence-as-a-Service,
POST /public/2025-04-01/evidenceresponds within_progress, andevidence.readyfollows with the file link.Review and decide
Review the package and decide whether to fight or accept the loss.
Submit through the provider
Submit through the provider endpoint before the deadline field says otherwise.
Reconcile status and money
Reconcile the final status and the money movement, for example Stripe
charge.dispute.funds_withdrawnandcharge.dispute.funds_reinstated.
Each step has a failure case, such as a missing merchant mapping, an ambiguous transaction or incomplete evidence. Route those cases to an exception queue well before the response deadline.
Evidence generation is not submission
An evidence API returns a document or structured output for a case. That output does not establish that a response reached the processor, and sending it is the chargeback representment step. Chargeflow's Evidence-as-a-Service returns one versioned PDF per dispute, and the documented flow is to verify the webhook signature, download and store the PDF, then submit it to your PSP before the dispute's due_by, the deadline stored on the dispute record. Automated chargeback evidence generation explains how the package is assembled, and the chargeback evidence source map shows which system usually holds each proof.
In a hybrid model the platform uses generated evidence inside its own submission process. It must keep package review, decision authority and a record of the version actually sent. The table shows that split for Evidence-as-a-Service.
| Paso | What the Chargeflow documentation covers | What stays with your platform |
|---|---|---|
| Generate evidence | A versioned PDF plus structured data for a dispute in needs_response | Sending dispute data, storing the PDF and keeping the evidence.id |
| Review before sending | A co-pilot option where a human approves before submission | Naming the reviewer and recording the decision |
| Submit the response | Guidance to submit the PDF to your PSP before the dispute's due date | Calling the processor endpoint from the tables above |
| Report the outcome | No public endpoint yet to report won or lost results | Reconciling the final status from processor events |
The automated chargeback management guide describes where each step normally sits.
Build reliability into the case model
Chargeflow evidence endpoint · check current case state first
Different generation states need different actions
A timeout is ambiguous: the operation may have completed even though the caller never saw the response. Reconcile current case state before repeating a consequential call.
504_generation_timeout
504 Retry the generation request, following the endpoint’s documented timeout handling.
409_generation_in_progress
409 Do not retry. Wait for evidence.ready or evidence.error instead.
Events are notifications, not a recovery mechanism. Reconcile through list endpoints after an outage, such as Stripe's GET /v1/disputes with a created filter, and never let a delayed event overwrite a newer state. Delivery rules differ: Stripe retries live events for up to three days and does not guarantee order (Stripe webhooks), Adyen queues failed webhooks and retries them for up to 30 days (Adyen webhook troubleshooting), and Chargeflow retries until your endpoint returns a 2XX response or its retry limit is reached. Neither Adyen nor Chargeflow states an ordering guarantee, and Chargeflow publishes no retry count or schedule, so treat those as unspecified. Dispute webhooks covers delivery design in detail.
Version evidence separately from the case. Store evidence.id rather than the download URL, which expires 7 days after issue, and expect file_version to increment on each regeneration. After evidence.error, which fires once automatic retries are exhausted, nothing retries until Generate Evidence is called again. The merchant API returns 429 with a Retry-After header, and numeric rate limits are still to be published.
Protect tenant boundaries and data access
Illustrative collision · two merchants can share an order number
An order number needs merchant context
Merchant A
1001 Example order number for the first merchant.
Merchant B
1001 The same example order number for a different merchant.
Keep the tenant in every match and access decision. A valid dispute ID alone should never bypass the platform’s authorization check.
Limit credentials to the scope each service needs, preserve provenance for evidence inputs and log identifiers and status rather than the evidence itself.
Chargeflow merchant API and platforms API
Chargeflow documents two API surfaces under the same version path, 2025-04-01. They are not interchangeable. The merchant API overview describes the route where you recover your own disputes, and the platform overview describes Connect for platforms.
| Aspecto | Merchants API | Platforms (Connect) API |
|---|---|---|
| Objetivo | You recover your own disputes | A platform or PSP sends disputes for the merchants it serves |
| Access | Keys generated in Settings, then Developers | Connect account invited by your account manager; keys from the Developer Hub; a Chargeflow account for each merchant |
| Authentication | x-api-key header; HMAC signing optional | x-api-key header; HMAC verification optional |
| Documented resources | Disputes, Alerts, Customer Communication, Webhooks Management, Webhooks Events, Data Subject | Accounts, platform disputes, evidence generation |
| Core calls | GET /public/2025-04-01/disputes, GET /public/2025-04-01/disputes/{disputeId}, PATCH /public/2025-04-01/disputes/{disputeId}, POST /public/2025-04-01/disputes/{disputeId}/evidence | POST /public/2025-04-01/accounts, POST /public/2025-04-01/platform/disputes, POST /public/2025-04-01/evidence |
| Webhooks | Dispute and alert events | dispute.created, evidence.ready, evidence.error, integration.access.error; signature header x-chargeflow-hmac-sha256 |
| Entitlement | No separate entitlement stated on the overview page | Evidence-as-a-Service is enabled per platform; otherwise calls return 403_eaas_not_enabled |
| Test environment | One environment, keys act on the live account; sandbox listed as coming | Platform and Evidence-as-a-Service sandbox listed as coming soon |
Sources: Chargeflow documentation for the Merchants API, Platforms API, Disputes, Accounts and platform webhook events, checked 11 October 2026.
A platform dispute also accepts optional suscripción and order objects, created_at and due_by are ISO 8601, and stage accepts Contracargo (the default), Consulta, Pre_arbitration or Arbitraje. Evidence generation only works while the dispute is in needs_response; otherwise the error is 422_dispute_invalid_state. Generation typically finishes in about 30 seconds and takes up to about 3 minutes. The Evidence-as-a-Service documentation and the platform webhook documentation hold the full references.
The platform overview lists four delivery models. Evidence-as-a-Service and Co-Branded are available today, White-Label is in beta and Alerts-as-a-Service is marked soon. Evidence-as-a-Service is for ISVs, platforms and PSPs, not for merchants of record. White-label chargeback management and embedded chargeback management compare the two heavier models, and the Chargeflow Connect launch post introduces the product. Once Alerts-as-a-Service ships, chargeback alerts are the pre-dispute layer it will cover.
For the merchant-side view of processor disputes on Stripe, Shopify and PayPal, see payment platform disputes.
Evaluate the API with realistic cases
Ask for the current schema, authentication method, supported business models, access requirements and versioning policy. Then test missing inputs, repeated requests, corrected evidence, merchant offboarding and cases close to the deadline. One clean demo case does not show production readiness, and cases blocked on missing merchant information show up in readiness and handoff metrics before they show up in request success. In-house versus outsourced chargeback management helps frame who owns each gap you find.
Preguntas frecuentes
What is a dispute API?
A dispute API is a programmatic interface that exposes dispute cases and the actions available on them, such as reading a case, submitting evidence or accepting the loss. Processor dispute APIs from Stripe, Adyen and PayPal handle case management, while evidence services assemble the response package.
How does Stripe handle disputes through its API?
Stripe creates a dispute object when a cardholder disputes a payment and sends a charge.dispute.created event. You read it with the Disputes API, submit evidence with a POST to /v1/disputes/{id} antes evidence_details.due_by, and accept the loss with /close. Evidence can typically be submitted only once.
Does a chargeback API automatically submit disputes?
No. A chargeback API submits a dispute only if it documents a submission endpoint and your account can use it. Case retrieval, evidence generation and submission are separate capabilities, and some APIs cover only one of them.
How do I submit dispute evidence through an API?
Each processor uses a different call. Stripe takes an evidence hash on the dispute update endpoint, Adyen takes documents through /supplyDefenseDocument followed by /defendDispute, and PayPal takes a multipart request to provide-evidence. Submit only after your own review step.
Where is the response deadline in each dispute API?
The deadline sits in a different field for each provider: evidence_details.due_by on Stripe, defensePeriodEndsAt in Adyen dispute webhooks and seller_response_due_date on PayPal. Store it as an absolute timestamp when the case is ingested.
Can I use an evidence API with my existing submission flow?
Yes. A hybrid model can combine partner-generated evidence with a platform's own submission flow, provided the platform defines package review, version tracking and submission ownership.
What is the difference between Chargeflow's merchant API and platforms API?
Chargeflow's merchant API lets a merchant read and enrich its own disputes and upload evidence. The platforms API lets a platform create merchant accounts, submit disputes and generate versioned evidence PDFs, and it requires a Connect account.
Evaluate dispute integration scope with Chargeflow Connect.

Contracargos?
Ya no es problema tuyo.
Recupera cuatro veces más Contracargos y prevención , hasta un 90 % de las entradas, gracias a IA y a una red global de 20 000 comercios.













.png)
.jpg)

