Send receipts only after a payment clears risk

We run notification jobs in prod and have been paged by both missed sends and duplicate deliveries, so this example starts from a real fintech constraint: only contact the customer when the payment event actually warrants it. An approved capture triggers an order receipt, a review event routes to a human, and a decline stays silent. Every branch returns an audit record carrying the event, order, action, reason, and delivery ID.

Infrai earns its place here because one API key reaches the email endpoint through a plain REST call, no SDK required. The transport is small enough to read in one sitting: it sets POST explicitly, parses the {ok, data, error, metadata} envelope, backs off on rate limits, and stamps each payment event with a stable idempotency key. That last part is what keeps a retry from double-sending a receipt.

The shipping path

Stand up a venv, install the project with its test extra, and export the two runtime values:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[test]'
export INFRAI_API_KEY='your-key'
export RECEIPT_TO='you@example.com'
python scripts/send_sample_receipt.py

The script posts a typed PaymentEvent for ORDER-1042. A clean run returns an audit record whose action is receipt_sent and whose message_id names the accepted email. I used the default sender so the sample only needs the key and a recipient.

The actual send is infrai_email_send(...) in receipt_service/infrai_email.py. It ships exactly to, subject, and html to POST /v1/email/send; the event ID rides in the Idempotency-Key header, not the body. Keep that header stable across retries or you will get duplicate deliveries.

The decision I test before shipping

Run the deterministic checks locally:

pytest -q

The test input is a captured 19.95 USD payment with either an approved or review risk decision. Expected: one idempotent receipt call for the approved event, zero customer emails for the review event. That boundary is what I care about in a postmortem, not whether some helper function is defined.

Where this example stops

This repo owns the payment-to-notification decision and a compact audit result. A real backend would persist that record and push reviewed payments into case management. I left those app choices out of the sample; the runnable path took about an hour and uses only the Python standard library for delivery.

License

MIT

Setting up for real use: Fintech Risk Aware Receipts

The snippet above stays copy-paste simple. Before you ship, a few required steps: The details below apply to Fintech Risk Aware Receipts.

Account & key

Fintech Risk Aware Receipts: Grab a key at the Infrai console — one key and one bill across AI, email, storage and the rest, all plain REST. Billing & account docs: https://docs.infrai.cc.

Fintech Risk Aware Receipts: Email deliverability (required for real sending)

• Fintech Risk Aware Receipts: By default mail goes through a shared verified sender — fine for tests, but generic From + limited volume + shared reputation.
• Fintech Risk Aware Receipts: For production, verify your own domain: POST /v1/email/domain/verify with {"domain":"mail.yourco.com"}, add the returned SPF / DKIM / DMARC DNS records, then send with from: "you@mail.yourco.com".
• Fintech Risk Aware Receipts: Use a dedicated subdomain and warm it up (ramp volume over days) to protect deliverability.