What is a chargeback responder?

A small serverless system that responds to payment disputes (chargebacks) on your behalf. The moment the payment processor reports a dispute, it gathers the evidence a bank actually weighs — the order record, proof of delivery and tracking, the customer’s own messages, and the refund and shipping policy the customer agreed to — and uses Bedrock to assemble a structured rebuttal mapped to the dispute’s reason code. It files the response through the processor’s API before the deadline and tracks whether you win or lose. It never invents evidence, and if a case is unwinnable it recommends accepting the loss instead of wasting the effort and the fee.

How much does it cost to run?

About $2.40/month at typical small-business volume (around 25 disputes a month). The fixed AWS cost is essentially zero — no always-on compute, no NAT Gateway, no API Gateway. The single biggest variable line is the Bedrock call that assembles each rebuttal packet; after that it is two small Secrets Manager secrets at $0.40 each, and a handful of pennies for Lambda, DynamoDB, S3, SES, SQS, EventBridge, and CloudWatch. At ten times the volume (around 250 disputes a month) it lands around $13, because only the per-dispute Bedrock cost grows.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with a Function URL for the processor webhook and a second for the file/hold approval buttons, EventBridge (a rule on the dispute events plus Scheduler for the one-off deadline watch), DynamoDB on-demand for the disputes, the evidence index, and the deadlines, S3 for the gathered evidence and the compiled packet PDF, SES (outbound only) to alert the owner, SQS with a dead-letter queue to buffer the gather-and-assemble work, Secrets Manager for the processor and carrier API keys, CloudWatch Logs at 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to assemble the rebuttal. No API Gateway, no NAT Gateway, no always-on compute. One region throughout: eu-west-2.

What evidence does it gather?

Four things, because those are what a card network’s representment rules actually ask for. The order record (what was bought, when, for how much, and the billing and shipping details). Proof of delivery and tracking (the carrier’s confirmation, timestamp, and signature or photo where there is one). The customer’s own messages (the support thread or chat where they asked about, used, or acknowledged the order). And the refund and shipping policy the customer agreed to at checkout, with the version and the timestamp of their acceptance. The system pulls each from its real source — it never writes evidence that did not exist.

Yes, but only to assemble — never to invent. Bedrock’s Claude Haiku 4.5 reads the gathered evidence and the dispute’s reason code and writes a structured rebuttal that ties each piece of real evidence to the specific claim the bank is testing. It also gives an honest winnability read. It is grounded strictly in the evidence on file: if proof of delivery is missing, the packet says so rather than fabricating a tracking number, and the system recommends accepting the loss. The decisions that touch money — whether to file, and the hard deadline — are deterministic code, not a model.

Can it file a response on its own?

It can, and how much it does on its own is a setting. In owner-approval mode it assembles the packet, emails you a summary with File, Hold, and Accept-loss buttons, and waits for your tap. In auto-file mode it files a winnable packet automatically once assembled. Either way a deadline guard sits underneath: a one-off EventBridge Scheduler job fires a safe margin before the bank’s due date, and if nothing has been filed and you haven’t chosen to accept the loss, it files the assembled packet rather than let the case lapse — because filing real evidence beats a guaranteed default loss. It never files late, and it never files evidence it does not have.

Series · 7 parts Published June 30, 2026

Chargeback responder

A customer files a payment dispute — a chargeback — and the clock starts the moment it lands: the bank wants your evidence within a tight window, and miss it and you lose by default. This is a small serverless system that catches the dispute the instant the processor reports it, gathers the evidence a bank actually looks at — the order, proof of delivery and tracking, the customer’s own messages, and the refund and shipping policy they agreed to — and uses Bedrock to assemble a structured, on-point rebuttal packet. It files the response through the processor’s API well before the deadline and tracks the outcome, and it never fabricates evidence: if a case is unwinnable it says so and recommends taking the loss rather than burning the fee. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A chargeback responder on AWS for a few dollars a month

The whole system on one page — a dispute intake, an evidence-and-packet engine, and a filing desk that beats the deadline — plus the four kinds of evidence every rebuttal is built from and the one rule underneath it all: never fabricate.
02

How a dispute gets caught

How a dispute is caught the moment it happens: a signed processor webhook hits a Lambda Function URL, the signature is verified, the event is de-duplicated, the bank’s evidence deadline is recorded, and a one-off deadline watch is armed — all before any evidence is gathered.
03

How the evidence gets gathered

How the evidence gets gathered: one Lambda pulls the four things a bank actually weighs — the order record, proof of delivery and tracking, the customer’s own messages, and the agreed policy — each from its real source, into an S3 evidence bucket and a DynamoDB index, recording honestly where a piece is missing.
04

How an evidence packet gets built

How an evidence packet gets built: Bedrock reads the gathered evidence and the reason code, ties each real piece to the specific claim the bank is testing, renders a structured packet PDF, and gives an honest winnability read — recommending you accept the loss when the evidence isn’t there.
05

How a response gets filed on time

How a response gets filed on time: the deadline watch is the spine of this post — a one-off EventBridge Scheduler job fires a safe margin before the bank’s due date, the owner’s File/Hold/Accept choice is honoured, and if nothing has been filed the deadline guard files the assembled packet rather than ever let a case lapse.
06

What the chargeback responder costs

What the chargeback responder costs: a line-by-line breakdown that sums to about $2.40/month at ~25 disputes, dominated by the Bedrock packet-assembly call, plus what it looks like at ten times the volume — and why a single recovered order pays for a year of it.
07

Engineering reference: the chargeback responder architecture

The engineering reference: the full AWS topology, the Lambda inventory with runtimes, the EventBridge rule and Scheduler deadline-watch config, the three DynamoDB tables and their key schemas, the S3 evidence bucket, the SES and Function URL setup, IAM scopes, the Bedrock model id, and the region.

What is a chargeback responder?: A small serverless system that responds to payment disputes (chargebacks) on your behalf. The moment the payment processor reports a dispute, it gathers the evidence a bank actually weighs — the order record, proof of delivery and tracking, the customer’s own messages, and the refund and shipping policy the customer agreed to — and uses Bedrock to assemble a structured rebuttal mapped to the dispute’s reason code. It files the response through the processor’s API before the deadline and tracks whether you win or lose. It never invents evidence, and if a case is unwinnable it recommends accepting the loss instead of wasting the effort and the fee.
How much does it cost to run?: About $2.40/month at typical small-business volume (around 25 disputes a month). The fixed AWS cost is essentially zero — no always-on compute, no NAT Gateway, no API Gateway. The single biggest variable line is the Bedrock call that assembles each rebuttal packet; after that it is two small Secrets Manager secrets at $0.40 each, and a handful of pennies for Lambda, DynamoDB, S3, SES, SQS, EventBridge, and CloudWatch. At ten times the volume (around 250 disputes a month) it lands around $13, because only the per-dispute Bedrock cost grows.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with a Function URL for the processor webhook and a second for the file/hold approval buttons, EventBridge (a rule on the dispute events plus Scheduler for the one-off deadline watch), DynamoDB on-demand for the disputes, the evidence index, and the deadlines, S3 for the gathered evidence and the compiled packet PDF, SES (outbound only) to alert the owner, SQS with a dead-letter queue to buffer the gather-and-assemble work, Secrets Manager for the processor and carrier API keys, CloudWatch Logs at 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to assemble the rebuttal. No API Gateway, no NAT Gateway, no always-on compute. One region throughout: eu-west-2.
What evidence does it gather?: Four things, because those are what a card network’s representment rules actually ask for. The order record (what was bought, when, for how much, and the billing and shipping details). Proof of delivery and tracking (the carrier’s confirmation, timestamp, and signature or photo where there is one). The customer’s own messages (the support thread or chat where they asked about, used, or acknowledged the order). And the refund and shipping policy the customer agreed to at checkout, with the version and the timestamp of their acceptance. The system pulls each from its real source — it never writes evidence that did not exist.
Does it use AI?: Yes, but only to assemble — never to invent. Bedrock’s Claude Haiku 4.5 reads the gathered evidence and the dispute’s reason code and writes a structured rebuttal that ties each piece of real evidence to the specific claim the bank is testing. It also gives an honest winnability read. It is grounded strictly in the evidence on file: if proof of delivery is missing, the packet says so rather than fabricating a tracking number, and the system recommends accepting the loss. The decisions that touch money — whether to file, and the hard deadline — are deterministic code, not a model.
Can it file a response on its own?: It can, and how much it does on its own is a setting. In owner-approval mode it assembles the packet, emails you a summary with File, Hold, and Accept-loss buttons, and waits for your tap. In auto-file mode it files a winnable packet automatically once assembled. Either way a deadline guard sits underneath: a one-off EventBridge Scheduler job fires a safe margin before the bank’s due date, and if nothing has been filed and you haven’t chosen to accept the loss, it files the assembled packet rather than let the case lapse — because filing real evidence beats a guaranteed default loss. It never files late, and it never files evidence it does not have.

All posts

Frequently asked questions

Other series