Back to blog

Building an Order-Evidence Trail for Digital Resellers

FazerCards
Building an Order-Evidence Trail for Digital Resellers

Digital goods move in seconds, and so do fraudulent dispute claims. The moment a buyer hits "dispute" with their payment processor, you have days — not weeks — to prove the transaction was legitimate and the product was delivered. Resellers who win these cases consistently are not the ones with the best lawyers; they are the ones who logged every step of the order lifecycle before the dispute opened. This guide walks through exactly what to capture, how to structure it, and how to generate a dispute file that payment processors actually act on.

Why Evidence Trails Decide Disputes

A chargeback review is not a hearing where you explain what happened. It is a document review where the processor compares your evidence against the buyer's claim. "We delivered the code" is an assertion. "We delivered the code at 14:32:07 UTC — here is the webhook payload signed by the fulfillment layer and a read receipt from the delivery channel" is evidence. Processors default to the buyer when evidence is absent or unclear; they default to the merchant when the evidence trail is complete, timestamped, and internally consistent.

The FazerCards platform provides a REST API and webhook infrastructure that timestamps every fulfillment event on the platform side — independent of your own records — giving you a two-source trail no buyer assertion can easily contradict. Understanding how to capture and retain that data is the core skill this guide develops. For a primer on the API and webhook mechanics, see the guide to wholesale gift card API and webhooks.

The Four Evidence Layers Every Order Needs

Layer 1: Order Receipt Data

Your internal order record is the foundation. At minimum, each row must hold:

  • Your storefront order ID and the upstream fulfillment reference ID
  • Buyer identifier — email hash, account UID, or platform-specific ID
  • Product SKU, denomination, and region
  • Payment method: card last four, or crypto transaction ID if funded via Binance Pay or USDT
  • Payment processor transaction ID and authorization code
  • Checkout session IP address and UTC timestamp, accurate to the second

A salted hash of the email preserves linkability to your full buyer record while protecting the raw value from appearing in plain text in your order logs.

Layer 2: Webhook Event Capture

The FazerCards webhook API fires events at each fulfillment milestone: order accepted, product sourced, code dispatched. Each payload contains a unique event ID, order reference, and UTC timestamp. Store these payloads verbatim — raw JSON, including the signature header — to an append-only store before any processing logic touches them.

  • Log every inbound webhook body as raw JSON to an append-only table or write-once object store
  • Capture the signature header to prove payload authenticity in a dispute
  • Index the log by order ID so retrieval during a dispute takes seconds, not hours
  • Set storage lifecycle to 180 days minimum; remove delete permissions from the bucket or table

This layer is what distinguishes "our platform says it was delivered" from a machine-generated, cryptographically verifiable record of the exact fulfillment moment — issued by a third party independent of your storefront.

Layer 3: Delivery Confirmation

For digital goods, delivery is the moment the code reaches the buyer's session. Capture:

  • UTC delivery timestamp
  • Delivery channel: storefront page render, email dispatch, Telegram bot message, etc.
  • Channel-specific message ID: the email provider's accepted ID, or the Telegram message ID
  • Read receipt or click event if your channel supports it

"I sent the code" is an assertion. "Message ID 4902837 was delivered at 14:32:19 UTC with a confirmed read receipt" is evidence. Log the channel-specific message ID alongside the order record in the same database so the two are always linked.

Layer 4: Enriched Buyer Profile

At the moment of purchase — not at dispute time — snapshot:

  • Account age in days and total prior order count on your platform
  • Prior dispute or refund history and outcomes
  • Checkout IP and whether its geolocation matches the billing country
  • Device fingerprint if your storefront captures it
  • Whether multiple orders were placed in a short window before the disputed order

A buyer disputing a code 20 minutes after delivery, with a one-day-old account and a mismatched IP, looks very different to a processor than a two-year-old account with 80 prior orders and zero dispute history. That profile snapshot, captured at checkout, becomes exhibit five in your dispute file.

Building the Dispute File

When a dispute opens, you need one coherent document — not a folder of screenshots. Structure it as:

  1. Summary — order ID, product, amount, buyer ID, payment method, fulfillment UTC timestamp, delivery UTC timestamp, buyer account age.
  2. Payment processor record — the transaction receipt showing authorization and capture, exported directly from your processor.
  3. Fulfillment webhook log — raw JSON payload(s) from the FazerCards webhook API, including event timestamps and order references.
  4. Delivery log extract — timestamped record from your delivery channel showing transmission to the buyer's session.
  5. Buyer profile snapshot — account age, order history, IP geolocation match status, prior dispute count.
  6. Communications log — all buyer messages before and after the order, with UTC timestamps.

Submit within 24 hours of the dispute opening. Processors typically allow 7 days, but a concise four-page submission within 24 hours signals an organised operation; a 20-page dump at hour 167 reads as scrambling.

Fraud Patterns Your Trail Catches

Buyer redeems a code, then claims it never arrived

Likely cause: Opportunistic claim after successful redemption. Verify: If the product platform surfaces redemption events, cross-reference. Otherwise rely on your delivery timestamp predating the dispute by hours or days. What your trail proves: Delivery timestamp plus a buyer profile showing no prior disputes plus IP match at checkout defeats this in most processor reviews.

Buyer claims the code was already used when delivered

Likely cause: Legitimate sourcing error, or buyer redeemed the code and then disputed. Verify: Your fulfillment webhook payload shows the code was sourced through an automated pipeline with a platform-generated timestamp. Compare that against any redemption timestamp obtainable from the product platform. If redemption occurred after your delivery timestamp, the sequence proves the buyer redeemed it before disputing. What your trail proves: Webhook sourcing timestamp plus delivery timestamp plus available redemption data.

Buyer disputes a subscription top-up claiming they did not authorise the charge

Likely cause: Impulse remorse or confusion about recurring billing. Verify: Pull the checkout session log showing the buyer confirmed the product, denomination, and any billing acknowledgment at a specific UTC timestamp. What your trail proves: Checkout confirmation event with IP, timestamp, and terms-acceptance record.

Implementation Checklist

  1. Create an append-only orders table with fields covering all Layer 1 data points; add indexes on buyer ID and payment transaction ID.
  2. Wire a webhook receiver endpoint via the FazerCards webhook docs that writes raw JSON payloads to immutable storage before any processing runs.
  3. For every delivery channel, log the channel-specific message ID and UTC delivery timestamp alongside the order record in the same database.
  4. Add a buyer profile snapshot step to your checkout pipeline that writes account age, order count, and prior dispute count into the order record at payment time — not at dispute time.
  5. Build a dispute-file generator: a script that accepts an order ID and queries your orders, webhooks, and delivery tables to produce a structured document in PDF or markdown format.
  6. Test the generator against synthetic orders before you need it under pressure; verify the output includes the webhook signature header.
  7. Set storage retention to 180 days minimum — most card networks allow chargebacks up to 120 days post-transaction, so 180 days covers the window.
  8. Review the FazerCards supplier vetting standards to understand provenance verification upstream — referencing this in a dispute response strengthens the argument that you operated a diligent supply chain.

FAQ

How long should I keep order evidence records?

Keep the full evidence trail for at least 180 days per order. Card network rules typically allow chargebacks up to 120 days after a transaction date, and some schemes extend this window. Configuring automated lifecycle policies on your storage to delete at 180 or 365 days handles retention without manual cleanup.

Does FazerCards provide fulfillment timestamps I can cite in a dispute?

Yes. Every webhook event from the FazerCards platform includes a UTC fulfillment timestamp and a unique event ID, and the API documentation explains how to verify the webhook signature. This makes the payload citable as a third-party-issued, machine-generated record — not just your own internal log.

What if a payment processor asks how I know the sourced code was not already used?

The webhook payload shows the code was sourced through an automated fulfillment pipeline at a specific platform-generated timestamp. FazerCards publishes its supplier vetting standards covering provenance verification — referencing this in your response establishes that the supply chain includes sourcing-side checks before delivery. Combined with your delivery log, the chronological sequence is clear.

Can crypto funding eliminate chargeback risk entirely?

Crypto-funded orders — via Binance Pay or USDT, supported on the FazerCards platform — have no card-chargeback mechanism by design. They do not eliminate all dispute paths, but they remove the payment-processor chargeback channel entirely. For high-risk buyer profiles or product categories, crypto funding combined with a complete evidence trail is the strongest position available. Explore platform pricing and plan options for details on crypto funding.

Start your free 5-day Gold trial and access the FazerCards webhook infrastructure, instant delivery pipeline, and 10,000+ product catalog from day one — with the evidence layer built in.