Chargeback feedback upload

Send historical chargeback outcomes through DEUNA so the configured anti-fraud provider can learn from confirmed results. This is a model-feedback workflow; it does not create a processor dispute, submit evidence, or manage an active chargeback case. Use Dispute Management for active disputes.

Feedback lifecycleAsk Athia about this#

Before you startAsk Athia about this#

Confirm all of the following with your TAM:

• the anti-fraud connection that will consume the feedback;
• whether email, SFTP, or both are enabled;
• the environments and transaction types accepted by each channel;
• the provisioned SFTP hostname, port, username, server-host-key fingerprint, and merchant directories;
• whether a result file is generated and how long processing normally takes for your account;
• the approved encryption, retention, and escalation requirements.

You also need the DEUNA transaction ID for every record. Do not substitute an order token, processor transaction ID, or merchant chargeback ID.

Record schemaAsk Athia about this#

Option A: approved email deliveryAsk Athia about this#

Use this option only when DEUNA has approved an email workflow for the target environment.

1. Export a CSV with the field names in the schema table.
2. Name it with your assigned merchant identifier and the agreed date convention. Use placeholders while building automation, for example YOUR_MERCHANT_ID-DDMMYY.csv.
3. Validate every required value and ensure the CSV is encoded consistently.
4. Send it only to the recipient confirmed for your account through an approved business mailbox.
5. Retain the delivery and reconciliation evidence required by your policy.

transaction_id,external_id,chargeback_identifier,chargeback_status,chargeback_reason_code,chargeback_case_id,merchant_chargeback_id,chargeback_amount,detail,chargeback_date
DEUNA_TRANSACTION_ID,MERCHANT_RECORD_ID,ACQUIRER_REFERENCE,open,REASON_CODE,PROVIDER_CASE_ID,MERCHANT_CASE_ID,2000,Confirmed fraud outcome,2026-10-30T11:20:00Z

DEUNA_TRANSACTION_ID is an explicit placeholder. Replace it with a real transaction ID from your protected export process; do not copy example identifiers into production.

Option B: provisioned SFTP deliveryAsk Athia about this#

Use SFTP only after DEUNA has created the account and supplied the expected connection values through an approved channel.

1. Create a dedicated SSH key

Generate a modern key pair on the trusted machine or workload that performs the upload:

ssh-keygen -t ed25519 -a 100 -f ./deuna_chargeback_upload

Protect the private key with the controls required for that workload. Share only deuna_chargeback_upload.pub through the approved onboarding channel. Never paste the private key into a ticket, chat, documentation, repository, or client application.

2. Verify the provisioned server

Before the first connection, compare the server-host-key fingerprint with the value supplied out of band by DEUNA. Do not accept an unexpected key just to continue.

sftp -i ./deuna_chargeback_upload YOUR_SFTP_USER@YOUR_SFTP_HOST

YOUR_SFTP_USER and YOUR_SFTP_HOST are placeholders. Use the values issued for the intended environment; sandbox and production can have different accounts and host keys.

3. Create the JSON batch

The JSON body contains the schema version and a records array:

{
  "version": "1.0",
  "records": [
    {
      "transaction_id": "DEUNA_TRANSACTION_ID",
      "external_id": "MERCHANT_RECORD_ID",
      "chargeback_identifier": "ACQUIRER_REFERENCE",
      "chargeback_status": "open",
      "chargeback_reason_code": "REASON_CODE",
      "chargeback_case_id": "PROVIDER_CASE_ID",
      "merchant_chargeback_id": "MERCHANT_CASE_ID",
      "chargeback_amount": 2000,
      "detail": "Confirmed fraud outcome",
      "chargeback_date": "2026-10-30T11:20:00Z"
    }
  ]
}

Use a unique YYYYMMDD_HHMMSS.json filename unless your provisioned contract specifies a different convention. Generate the filename in UTC to make batch correlation unambiguous.

4. Upload to the assigned inbound directory

After connecting, change to the exact directory issued for the environment and upload the file:

sftp> cd YOUR_ASSIGNED_INBOUND_DIRECTORY
sftp> put 20261030_112000.json
sftp> ls
sftp> bye

Do not construct a directory from a merchant ID unless the provisioned instructions explicitly require it. A successful put confirms transfer, not record acceptance.

5. Reconcile the result

If your account produces result files, retrieve the file from the assigned outbound directory and match it to the input batch. The filename and response schema can vary by provisioned contract; use the values supplied during onboarding.

sftp> cd YOUR_ASSIGNED_OUTBOUND_DIRECTORY
sftp> ls
sftp> get YOUR_RESULT_FILE.json
sftp> bye

Classify every record as accepted, rejected, or still unresolved. Correct rejected records before resubmission and avoid replaying accepted outcomes unless DEUNA support instructs you to do so.

Validation and idempotencyAsk Athia about this#

Validate a batch before transfer:

• version is the supported value 1.0 for JSON uploads;
• records is a non-empty array;
• every transaction_id belongs to the intended merchant and environment;
• every chargeback_date is a valid ISO 8601 timestamp with a timezone;
• every amount is an integer in minor units and uses the original payment currency;
• enum values and maximum lengths match the schema;
• the file name is unique and does not overwrite a prior batch;
• the file contains no columns or attributes outside the approved contract.

Keep a merchant-side batch record containing the file checksum, creation time, environment, transfer time, and per-record outcome. This evidence lets you retry rejected data without blindly resending the whole batch.

TroubleshootingAsk Athia about this#

When escalating, include the merchant ID, environment, filename, checksum, transfer timestamp, and sanitized error text. Never attach a private key, provider secret, raw card data, or an unredacted customer export.

Go-live checklistAsk Athia about this#

1. DEUNA confirms the target provider, environment, transfer channel, and account permissions.
2. Security verifies key custody, host-key validation, allowlisting, encryption, access, and retention.
3. A sandbox batch proves accepted and rejected record handling.
4. Operations can correlate every input record with its processing outcome.
5. Monitoring alerts on missing transfers, rejected records, and unresolved batches.
6. The production runbook names the owner and approved escalation channel.