Chargeback Disputes

A chargeback occurs when a customer contacts their financial institution to contest a payment they either do not recognize or disagree with, seeking compensation on their card bill.

• Fraud chargeback - This is the most common chargeback. The cardholder does not recognize a payment made with their card. It may be the result of a cloned card, a data leak, or some vulnerability that has breached the customer data.

• Commercial disagreement - This type of chargeback has nothing to do with fraud. The cardholder acknowledges the purchase—they bought it and know it—but they were not satisfied for some reason. It may be related to delivery problems, product or service quality, or a failed refund request.

• Friendly chargeback - This case is quite common. It happens when the owner of the card lends it to someone they know to buy an item, but the person takes advantage and buys other things as well. The card owner recognizes the buyer but not the additional purchases.

• Processing error - The credit card transaction was processed more than once because of a processing error.

What is a chargeback dispute

A chargeback dispute occurs when a merchant challenges a chargeback initiated by a customer. This process allows the merchant to present evidence to the issuing bank to prove the validity of the transaction and contest the customer’s claim. Chargebacks are granted under consumer protection laws and follow card scheme rules, which define the procedures, reason codes, and documentation required for disputes.

How it works

1. Customer initiates a chargeback - The customer contacts their card issuer to contest a transaction, citing reasons such as fraud, dissatisfaction with the product or service, or processing errors.

2. Funds deducted from merchant's settlement - When the chargeback is initiated, the amount is temporarily deducted from the merchant's settlement to cover the disputed charge.

3. Merchant submits evidence - To dispute the chargeback, the merchant provides documentation proving the transaction was legitimate. Evidence may include delivery confirmations, communication records, and proof of customer consent.

4. Issuer reviews the evidence - The issuing bank evaluates the evidence submitted by the merchant to decide whether the chargeback is valid.

5. Outcome

• If the merchant wins the dispute, the funds are credited back to their settlement.
• If the dispute is unsuccessful, the chargeback remains, and the process is concluded.

Chargeback reasons

Chargeback reasons provide a clear explanation of why a dispute was initiated by the customer. Understanding these reasons helps merchants identify areas for operational improvement, detect fraudulent consumer behavior, and address potential vulnerabilities in their processes.

Reason	Description
Unrecognized	The customer does not recognize the transaction.
Paid by other means	Double payments, or operational errors.
Processing error	Errors during payment processing.
Product not received	The customer did not receive the purchased item.
Overcharged	The charged amount was incorrect.
Product unacceptable	The item was different than expected.
Credit not processed	Refunds or credits not processed as expected.
Fraudulent	Unauthorized transactions due to data breaches or stolen cards.

Reason codes

Not all reasons allow disputes

Code	EBANX Description	Category	Group	Disputable
4863/75	Transaction not recognised	UNRECOGNIZED	Fraud	Yes
4837/83	Fraud (card-not-present)/No cardholder authorisation	FRAUDULENT	Fraud	Yes
4850/57	Installment dispute / Fraudulent Multiple Transactions	GENERAL	Fraud	Yes
4853/53	Not as described, defective merchandise or counterfeit	PRODUCT_UNACCEPTABLE	Commercial Disagreement	Yes
4855/30	Services not provided or merchandise not received	PRODUCT_NOT_RECEIVED	Commercial Disagreement	Yes
4841/41	Canceled/Non authorized Recurring Transaction	CREDIT_NOT_PROCESSED	Commercial Disagreement	Yes
4860/85	Credit not processed	CREDIT_NOT_PROCESSED	Commercial Disagreement	Yes
4846/76	Incorrect currency or transaction code	OVERCHARGED	Processing Error	No
4808/77	Non-matching account number/Authorisation related CBK	PROCESSING_ERROR	Processing Error	No
4842/74	Late presentment	PROCESSING_ERROR	Processing Error	No
0000/73	Expired card	GENERAL	Processing Error	No
4834/82	Duplicate processing	OVERCHARGED	Processing Error	No
4831/86	Paid by other means/ Transaction amount or account differs	PAID_BY_OTHER_MEANS	Processing Error	No
4849/93	Questionable merchant activity / Risk Identification Service	GENERAL	Other	No
0000/79	Retrieval request not received or illegible	GENERAL	CATB (MX only)	No
0000/78	Split transaction to avoid limit blockage	GENERAL	CATB (MX only)	No
0000/00	Reason code not available	GENERAL	Other	No
2000/01	Reason code not available	GENERAL	Other	No
2000/02	Reason code not available	GENERAL	Other	No
4837/104	Fraud (card-not-present)/No cardholder authorization	GENERAL	Fraud	Yes
4853/135	Not as described, defective merchandise or counterfeit	GENERAL	Commercial Disagreement	Yes
4853/134	Not as described, defective merchandise or counterfeit	GENERAL	Commercial Disagreement	Yes
4853/133	Not as described, defective merchandise or counterfeit	GENERAL	Commercial Disagreement	Yes
4855/131	Services not provided or merchandise not received	GENERAL	Commercial Disagreement	Yes
4855/137	Services not provided or merchandise not received	GENERAL	Commercial Disagreement	Yes
4841/136	Cancelled/Non authorized Recurring Transaction	GENERAL	Commercial Disagreement	Yes
4841/132	Cancelled/Non authorized Recurring Transaction	GENERAL	Commercial Disagreement	Yes
4860/138	Credit not processed	GENERAL	Processing Error	No
4846/123	Incorrect currency or transaction code	GENERAL	Processing Error	No
4846/122	Incorrect currency or transaction code	OVERCHARGED	Processing Error	No
4808/127	Non-matching account number/Authorisation related CBK	GENERAL	Processing Error	No
4842/121	Late presentment	PROCESSING_ERROR	Processing Error	No
0000/113	Expired card	GENERAL	Processing Error	No
4834/126	Duplicate processing	GENERAL	Processing Error	No
4831/124	Paid by other means/ Transaction amount or account differs	GENERAL	Processing Error	No
4831/125	Paid by other means/ Transaction amount or account differs	PAID_BY_OTHER_MEANS	Processing Error	No
4849/105	Questionable merchant activity / Risk Identification Service	GENERAL	Other	No
0000/102	Liability Shift Non-Counterfeit Fraud	GENERAL	Card Present Only	No
0000/112	Declined Authorization	GENERAL	Card Present Only	No
0000/127	Invalid data	PROCESSING_ERROR	Processing Error	No
0000/138	Original Credit Transaction Not Accepted (EUROPE ONLY)	CREDIT_NOT_PROCESSED	Commercial Disagreement	Yes
0000/139	Withdrawal at an ATM	PRODUCT_NOT_RECEIVED	Card Present Only	No
0000/72	The charge bears the signature of another person	GENERAL	Card Present Only	No
4515/80	Paid by other means/ Transaction amount or account differs	GENERAL	Processing Error	No
4527/103	Card-Present Environment/Condition	GENERAL	Card Present Only	No
4750/00	Car Rental Charge Non Qualified Or Unsubstantiated	GENERAL	Commercial Disagreement	Yes
4801/00	Cardholder Dispute	GENERAL	Cardholder Dispute	No
4807/111	Canceled Card Report	GENERAL	Authorization	No
4808/113	Declined Authorization	GENERAL	Authorization	No
4808/57	Instalment dispute / Fraudulent Multiple Transactions	GENERAL	Fraud	Yes
4835/73	Expired Card / Account	GENERAL	Authorization	No
4840/00	Fraudulent Processing of Transactions	GENERAL	Card Present Only	No
4850/00	Wrong number of Installment Billing	GENERAL	Processing Error	No
4859/00	ATM Dispute	GENERAL	Card Present Only	No
4870/101	Liability Shift Counterfeit Chip Fraud	GENERAL	Card Present Only	No
4901/000	Required Document Not Received to Support Second Presentment	GENERAL	Other	No
4902/000	Document Received was Illegible	GENERAL	Other	No
4903/000	Scanning Error - Unrelated Documents or Partial Scan	GENERAL	Other	No
5002/000	Required Document Not Received - Domestic	GENERAL	Other	No
5003/000	Required Document Not Received /Not recognized - Domestic	GENERAL	Other	No
0100/10	Found previous chargebacks registered	GENERAL	Fraud	Yes
0100/11	Found suspicious email formation	GENERAL	Fraud	Yes
0100/12	Found suspicious purchase attempts behavior	GENERAL	Fraud	Yes
0100/13	Found suspicious purchase history behavior	GENERAL	Fraud	Yes
0200/14	Found previous purchase using alternative payment method	GENERAL	Commercial Disagreement	Yes
0200/15	Found previous purchase using any credit card number for same merchant without refunds/chargebacks	GENERAL	Commercial Disagreement	Yes
0200/16	Found previous purchase using same credit card number for any merchant without refunds/chargebacks	GENERAL	Commercial Disagreement	Yes
0300/17	Fallback to Fraud Prevention manual review	GENERAL	Review	No
0900/10	EWallet Commercial Disagreement	GENERAL	Commercial Disagreement	Yes

Providing dispute evidence

To comply with card scheme rules and ensure a higher success rate for disputes, specific technical requirements must be followed when submitting evidence. These requirements aim to standardize the analysis process across card schemes.

Technical specifications

• File format: PDF
• Paper size: A4
• Maximum pages: 8
• File size limit: 2MB

Providing detailed and accurate documentation is critical to increase the chances of a successful dispute. Note that the responsibility for submitting truthful and comprehensive information lies with the merchant, not EBANX.

Recommended support documentation

Below are examples of documentation that can strengthen your dispute case. Consider the specifics of your business and market when preparing evidence.

• General documentation:

  • Customer support history (e.g., email, WhatsApp conversations, or other communication records).
  • Purchase and customer details (e.g., items purchased, customer name, product/service descriptions).
  • Confirmation emails.
  • Record of previous uncontested payments.
  • Proof that the cardholder verified the account before the transaction.
  • Proof of delivery (e.g., purchase tracking, service usage confirmation).
  • Customer validation (e.g., SMS or email confirmation).
  • Customer documents (if available).
  • Electronic receipts.
  • Delivery tickets.
  • Email history.
  • Customer purchase history.
  • Screenshot or document showing accepted terms and conditions.
  • Exchange and cancellation policy (e.g., product page policies).

• Specific documentation:

  • For goods:
    • Description of the products, including the purchase and delivery dates.
    • Delivery receipt signed by the carrier (e.g., DHL, UPS).
    • Purchase tracking printouts.
    • Communication confirming possession of goods by the cardholder.
    • Explanation of delayed shipments, if applicable.
  • For digital goods:
    • Description of the digital products, including purchase and download dates.
  • For services:
    • Documentation proving the service was provided (e.g., confirmation emails, invoices).
    • Start date of service usage.
    • Proof of prior service usage by the cardholder.
    • Record of previous uncontested payments.

Dispute process

Once evidence is submitted, EBANX will forward it to the acquirer, who will then send it to the issuing bank for review. The issuing bank will analyze the evidence and decide the final status of the dispute, which will reflect on your settlement.

By providing thorough, relevant, and accurate documentation, you can significantly improve the likelihood of a favorable outcome in chargeback disputes.

---

Managing disputes via Merchant Area

Once a dispute is initiated on the Merchant Area, evidence will be required to proceed with the process.

Overview page

A banner will appear on the Overview page of the Merchant Area, highlighting the number of affected transactions with chargeback disputes.

• The banner ensures that you stay informed and do not lose track of pending disputes requiring your attention.
• Only users with Admin and Customer Service roles will be able to manage disputes on the Dashboard, so it is important to keep users permissions updated.

Overview page - Chargeback dispute banner

Chargeback disputes page

The Chargeback Disputes page lists all transactions with disputes.

Search filters

To track and manage disputes, use the filters to narrow your search by status. Applying filters helps focus on specific stages of the dispute process and ensures no pending actions are overlooked.

Dispute statuses for search filter

• Processing - EBANX is handling the dispute internally, such as cases of friendly fraud.
• Evidence required - Merchant action is needed to submit evidence.
• Under analysis - Evidence is being reviewed by the issuing bank. This process can take up to 120 days.
• Dispute won - The dispute was resolved in your favor, and the chargeback amount will be credited to your settlement.
• Dispute lost - The dispute was unsuccessful, and no further actions are required.
• Not disputed - No evidence was submitted before the deadline, or the chargeback is considered valid.

Evidence submission

• Pay attention to the status Evidence Required, and the Respond until date.
• You must upload evidence before the deadline, otherwise your dispute will expire.
• By clicking on a dispute that requires evidence, you will be redirected to the payment page to submit evidence.

Accepting chargebacks

• If the cardholder and the merchant agree on the validity of the chargeback, there is no need to initiate a dispute process. In situations where fraud is recognized or a refund has failed and the customer requests a chargeback, the merchant can choose to accept the chargeback. This can help avoid unnecessary disputes and streamline the resolution process.
• Merchants can accept chargebacks by choosing Don’t dispute this Chargeback on the payment page.

Chargeback reversal

If a customer recognizes the transaction and withdraws the chargeback, it can be reversed through EBANX or the card issuer. Once reversed, the amount will be credited back to your settlement as a Chargeback Credit.

Reversed chargebacks will appear in the Chargeback section of the Payment Page for easy tracking, as shown in the example below.

---

Managing disputes via SFTP

In addition to the Merchant Area, you can manage disputes through an SFTP connection, enabling chargebacks and disputes to be handled efficiently via a file exchange process.

Key features of the SFTP solution include:

Daily chargeback dispute report - The Daily chargeback dispute report is generated daily and provides chargeback details and status updates since the last report. As the same transaction may progress through different statuses over time, it’s important to reference the report to track the latest updates.

• Report format

  • The report is saved in CSV format and can be found in the chargeback/notification/ directory.
  • Files are named using the generation date in the format: cbk_dispute_YYMMDD.csv.

• Report contents

  • This report provides insights into your chargeback management process, ensuring you stay informed and take timely actions.

  • The daily report includes the following columns:

    • Merchant payment code - The code of the payment that originated the chargeback.
    • Dispute time - The date and time the chargeback dispute was initiated.
    • Currency - The original currency of the payment.
    • Payment amount - The amount of the original payment in the original currency.
    • Reason - The reason for the chargeback, which could be one of the following:
      • Fraudulent
      • Unrecognized
      • Paid by Other Means
      • Processing Error
      • General
      • Product Not Received
      • Credit Not Processed
      • Overcharged
      • Product Unacceptable
    • Representment deadline: The due date for submitting evidence to dispute the chargeback.
    • Reason description: Additional details provided by the issuer bank regarding the chargeback.
    • Status: The current status of the chargeback or dispute.
    • Country: The country where the payment was processed.

Automated evidence submission via SFTP - This solution enables merchants to submit evidence documents in bulk through SFTP, streamlining the dispute process. By automating submissions, it eliminates the need to use the Dashboard, offering a faster, more efficient, and hassle-free approach to managing disputes.

Merchants can submit evidence files for disputes by following this workflow:

1. Save evidence files

   • Upload the evidence files to the chargeback/evidences_to_dispute/ directory via the SFTP connection.

2. File naming

   • The file name must match the Merchant Payment Code, and the file format must be PDF.
   • Example: BDA20030055.pdf

3. File requirements

   • The file must be a single PDF document per dispute.
   • The PDF can include both images and text.
   • Encryption or zipping is not required.

4. Automated collection

   • EBANX collects evidence files hourly, every day. Once the file is processed, it is automatically deleted from the directory.

---

Managing disputes via API

In addition to the Merchant Area and SFTP, you can submit chargeback dispute evidence programmatically through a dedicated API endpoint.

This endpoint only submits evidence — it does not return chargeback data or dispute statuses in its response. To track a chargeback programmatically, use the Payment Query API (POST /ws/query): when a payment has a chargeback, the response includes a chargeback node with chargeback_public_id, chargeback_date, reason_code, and dispute_status. You can also receive notification_type=chargeback events on your Notification URL, use the SFTP daily report, or check the Merchant Area.

A common integration pattern is hybrid: receive the chargeback notification via the SFTP report or Notification URL → submit evidence via this API → query POST /ws/query to confirm the dispute status changed to Under Analysis.

Getting started

Before submitting evidence via API, complete these steps once:

1. Generate an RSA key pair

Generate a 4096-bit RSA key pair. Keep your private key secure and never share it.

Shell

# Generate private key
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out private_key.pem

# Extract public key
openssl rsa -pubout -in private_key.pem -out public_key.pem

2. Register your public key with EBANX

Send your public_key.pem to your EBANX account team. EBANX will return a unique Key ID (kid) for each tenant and environment. You may register as many keys as needed — one per tenant and environment combination is recommended.

3. Store your kid and private key securely

Never share the private key — it signs every request on your behalf. The kid value is not sensitive and will be included in the JWS header of each request.

---

Prerequisite: chargeback must be awaiting evidence

Evidence can only be submitted when the chargeback is in the Evidence Required status — shown as NeedsResponse in the SFTP report and as "Evidence Required" in dispute_status from POST /ws/query. The response deadline displayed in the Merchant Area or the SFTP report must not have passed.

Attempting to submit in any other state returns:

Situation	Error
Dispute already finished	BP-CH-07
Evidence already submitted for this chargeback	BP-CH-06
Chargeback not disputable or handled by EBANX	BP-CH-09
Any other non-eligible status	BP-CH-03

Evidence submission is final. Once a 200 SUCCESS is returned, the file is attached and cannot be replaced or supplemented. If you need to submit multiple documents, consolidate them into a single PDF before sending.

---

Endpoint

http

POST /ws/chargeback/send-evidence

API hosts

Use the endpoint that matches the chargeback's tenant and environment. See the API endpoints reference for the supported endpoint combinations.

Environment	Host
Cross-border (production)	https://api.ebanxpay.com
Local (production)	https://api-local-latam.ebanxpay.com
Cross-border (sandbox)	https://sandbox.ebanxpay.com
Local (sandbox)	https://sandbox-local-latam.ebanxpay.com

Headers

Header	Value
Content-Type	multipart/form-data; boundary=<YOUR_BOUNDARY>
X-JWS-Signature	<JWS_TOKEN> — see Authentication below

Note: Most HTTP clients (cURL with --form, Postman, Axios) generate the Content-Type header and its boundary automatically when building a multipart request. If you must set it manually, include the correct boundary value — setting Content-Type: multipart/form-data without a boundary will break the request.

Request body (form-data)

The request uses multipart/form-data with two required fields:

Field	Type	Description
dispute_evidence	application/pdf	The evidence PDF file. Must be a valid, non-corrupted PDF (not encrypted or zipped). Maximum size: 15 MB (specific to this endpoint). The form part must declare Content-Type: application/pdf.
request_body	JSON string	A JSON string containing the payment identifier and the SHA-256 hash of the evidence file. This exact string must also be used as the JWS signing payload.

request_body parameters

Parameter	Required	Description
hash	Yes *	Payment hash. Mutually exclusive with merchant_payment_code. Prefer this if payment codes may not be unique.
merchant_payment_code	Yes *	Payment code. Mutually exclusive with hash.
dispute_evidence	Yes	SHA-256 hash of the evidence PDF binary content, as a lowercase hexadecimal string.

* Exactly one of hash or merchant_payment_code must be provided — not both.

---

Authentication (JWS)

This endpoint uses JSON Web Signature (JWS) with a detached payload (RFC 7515). The signing key must match the kid registered with EBANX for the target tenant and environment.

Steps to generate the X-JWS-Signature token:

1. Build the request_body JSON string — this is also your signing payload.

2. Compute the SHA-256 hash of the evidence PDF in hex and include it as dispute_evidence inside the JSON.

3. Prepare the JWS header: {"alg": "RS256", "kid": "your-key-id"}

4. Sign the JSON string with your RSA-4096 private key using the RS256 algorithm.

5. Assemble in compact serialization with detached payload:

   Text

   BASE64URL(HEADER)..BASE64URL(SIGNATURE)

   The middle section is intentionally empty — the payload is detached.

Critical: The request_body string sent in the form must be byte-for-byte identical to the payload used when generating the signature. Any difference — including key ordering, extra escape characters (\), or whitespace — will cause a signature mismatch and return a 401 authentication error.

---

Request example

Build the request_body JSON first, then reuse the same string for both the JWS payload and the form field.

Using merchant_payment_code:

JSON

{
  "merchant_payment_code": "YOUR_PAYMENT_CODE",
  "dispute_evidence": "a3f1c9d2e4b5f67890abcdef1234567890abcdef1234567890abcdef12345678"
}

Using hash instead:

JSON

{
  "hash": "YOUR_PAYMENT_HASH",
  "dispute_evidence": "a3f1c9d2e4b5f67890abcdef1234567890abcdef1234567890abcdef12345678"
}

cURL — Cross-border (production)

Shell

curl --location 'https://api.ebanxpay.com/ws/chargeback/send-evidence' \
  --header 'X-JWS-Signature: <YOUR_JWS_TOKEN>' \
  --form 'request_body="{\"merchant_payment_code\":\"YOUR_PAYMENT_CODE\",\"dispute_evidence\":\"a3f1c9d2e4b5f67890abcdef1234567890abcdef1234567890abcdef12345678\"}"' \
  --form 'dispute_evidence=@"/path/to/evidence.pdf";type=application/pdf'

cURL — Local (production)

Shell

curl --location 'https://api-local-latam.ebanxpay.com/ws/chargeback/send-evidence' \
  --header 'X-JWS-Signature: <YOUR_JWS_TOKEN>' \
  --form 'request_body="{\"merchant_payment_code\":\"YOUR_PAYMENT_CODE\",\"dispute_evidence\":\"a3f1c9d2e4b5f67890abcdef1234567890abcdef1234567890abcdef12345678\"}"' \
  --form 'dispute_evidence=@"/path/to/evidence.pdf";type=application/pdf'

---

Responses

Success (HTTP 200)

JSON

{
  "status": "SUCCESS"
}

A 200 SUCCESS response means the file was accepted and attached to the dispute — not merely received. All validations (authentication, hash integrity, chargeback eligibility) passed before the file was registered. It does not represent a decision on the dispute outcome; the issuing bank's review happens asynchronously.

Error

JSON

{
  "status": "ERROR",
  "status_code": "<ERROR_CODE>",
  "status_message": "<ERROR_MESSAGE>"
}

Error codes

Code	HTTP Status	Description
BP-CH-00	500	Internal or unknown error.
BP-CH-01	404	Requested resource not found. Check that the payment identifier exists in the correct tenant.
BP-CH-02	401	Unauthorized. Common causes: missing request_body, invalid kid, or wrong host.
BP-CH-03	422	Chargeback is not yet ready to accept evidence. Contact EBANX if the dispute appears eligible.
BP-CH-04	400	Invalid or missing parameters. Common cause: the dispute_evidence file field is missing from the request.
BP-CH-05	400	Uploaded file is invalid — corrupted, incomplete, wrong format, or exceeds the 15 MB size limit.
BP-CH-06	422	Evidence has already been submitted for this chargeback. Submission is final and cannot be repeated.
BP-CH-07	422	Dispute is already finished.
BP-CH-08	401	Signature verification failed. The SHA-256 hash in request_body does not match the uploaded file.
BP-CH-09	422	Chargeback is not disputable. May reflect a missing acquirer configuration — contact your EBANX account team.

---

Common integration issues

The following mistakes frequently cause failures during merchant integrations:

401 returned even when request_body is not empty

JWS authentication runs before body parameter validation. If request_body is absent or the JWS signature does not match the payload, the API returns a 401 authentication error — not 400. The exact error code (BP-CH-02 or BP-CH-08) depends on where the mismatch is detected. Always send both form fields and verify the payload matches exactly.

File field missing Content-Type: application/pdf

The dispute_evidence form part must declare its content type explicitly. Without Content-Type: application/pdf, the server treats the upload as plain text and the request fails. In cURL, always include ;type=application/pdf when referencing the file: @"/path/to/evidence.pdf";type=application/pdf.

request_body payload does not match the JWS signature

The JSON string in request_body must be byte-for-byte identical to the payload used to generate X-JWS-Signature. Differences in key ordering, extra escape characters, or whitespace will invalidate the signature. Serialize the JSON once and reuse the same string for both the signature and the form field.

Wrong host for the chargeback's tenant

Submit directly to the endpoint that matches the chargeback's tenant and environment. See the API endpoints reference for the supported combinations. Using an endpoint for another tenant or environment causes the request to fail.

kid not matching the target tenant or environment

A kid is scoped to the tenant and environment it was registered in. Using a Local kid against the Cross-border host (or vice versa) will cause authentication failures. Register one key per tenant and environment combination.

BP-CH-09 on chargebacks that should be disputable

This error can indicate that the acquirer is not enabled for disputes on that merchant's configuration. Contact your EBANX account team to review the dispute setup for the affected acquirer.

Retrying after a timeout

Evidence submission is final: once evidence is attached to a dispute, any repeated request returns BP-CH-06. If a request times out and you are unsure whether it was processed, query the payment (POST /ws/query) and check chargeback.dispute_status before retrying.

---

Status after submission

Once evidence is successfully submitted:

• Merchant Area and POST /ws/query: the dispute status changes to Under Analysis. Poll chargeback.dispute_status in the query response to confirm programmatically.
• SFTP daily report (cbk_dispute_YYMMDD.csv): this report is event-based and does not generate a new entry when evidence is submitted — the Disputed status (equivalent to Under Analysis) does not trigger an SFTP notification. The next entry for that chargeback will be its final outcome — Won, Lost, or Not_disputed. Note that this report uses a different status vocabulary from the Merchant Area and ws/query.

The table below maps each status across both channels:

Merchant Area / Payment Query API	SFTP daily report
Evidence Required	NeedsResponse
Under Analysis	—
Dispute Won	Won
Dispute Lost	Lost
Not disputed	Not_disputed

The submitted evidence file cannot be retrieved or downloaded after submission. To confirm the evidence was accepted and the dispute is progressing, query POST /ws/query and check that chargeback.dispute_status changed to "Under Analysis".

---

Dispute statuses

• Needs response - New chargeback, awaiting merchant action.
• Won - Dispute resolved in favor of the merchant.
• Lost - Dispute resolved against the merchant.
• Not disputed - No evidence submitted before the due date.

Financial flow

• Reversal on Settlement - Chargeback reversals credit the retained amount to the merchant's settlement once resolved.

Frequently asked questions

• Response timelines
  • Merchants have 5 business days to respond.
  • Banks may take up to 120 days for final resolution.
• Differences per acquirer - Behavior may vary by market and acquirer, including 3DS and fraud prevention rules.
• Auto disputes - EBANX does not perform automatic disputes for merchants.

Still need help?

We hope this article was helpful. If you still have questions, you can explore the following options:

• Merchant support: Contact our support team at sales.engineering@ebanx.com for assistance.
• Not a partner yet? Please complete the Merchant Signup Form, and our commercial team will reach out to you.