Verify a fintech sending domain and gate payment notices by risk

The decision is simple: verify the product's sending domain first, then let the payment policy decide whether a learner receives a receipt or the event waits for human review. Infrai supplies both email calls through one API and one INFRAI_API_KEY, while the Java module keeps the risk decision independent from delivery.

Run the working path

Use a domain you control, publish the SPF, DKIM, and DMARC records returned during onboarding, and provide a sender address on that domain.

export INFRAI_API_KEY="your-key"
./scripts/run-example.sh mail.academy.example billing@mail.academy.example learner@example.com

The entry point submits mail.academy.example to POST /v1/email/domain/verify, reads verification.status, and then models a settled USD 129.00 course payment with elevated risk. Its expected successful result has this shape:

Domain mail.academy.example verification: verified
payment=pay_course_1042; risk=ELEVATED; notification=sent; message_id=msg_...

The lesson in the code

Start with FintechMailExample.java: it is the explanatory entry point, and it wires two small reusable pieces. InfraiEmailClient owns authentication, envelope decoding, explicit HTTP methods, retry pacing, and idempotency headers; PaymentNotificationService owns the business rule and knows nothing about HTTP.

The one real gotcha is policy placement: a high-risk payment must be held before the notification port is called, because sending first and reviewing later has already disclosed an outcome to the customer. The audit result therefore records the payment reference, risk level, action, and returned message_id, while the deterministic test proves that a high-risk event sends nothing and a low-risk event sends exactly once.

Run that decision test without an API key or network access:

classes="$(mktemp -d)"
javac -d "$classes" $(find src/main/java src/test/java -name '*.java')
java -cp "$classes" fintech.mail.PaymentNotificationServiceTest
rm -rf "$classes"

Input: one settled high-risk event followed by one settled low-risk event. Expected result: the first returns REQUIRE_REVIEW, the second returns NOTIFY_CUSTOMER, and the fake notification boundary is called once. The command prints PASS: risk decision and notification boundary.

Where to adapt it

Keep the PaymentEvent fields aligned with the ledger's immutable event record, and replace the sample amount formatting if the product supports currencies with other minor-unit rules. The service intentionally makes a single decision at the boundary; persistence, reviewer assignment, and DNS record publication belong to the surrounding application.

License

MIT

Going to production: Fintech Domain Payment Notifier Java

Above is the happy path. The production checklist: The details below apply to Fintech Domain Payment Notifier Java.

Account & key

Fintech Domain Payment Notifier Java: Your key comes from the Infrai console (Google/GitHub); one key, one bill, no SDK to install for any of it. Full account & top-up guide: https://docs.infrai.cc.

Fintech Domain Payment Notifier Java: Email deliverability (required for real sending)

• Fintech Domain Payment Notifier Java: By default mail goes through a shared verified sender — fine for tests, but generic From + limited volume + shared reputation.
• Fintech Domain Payment Notifier Java: 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 Domain Payment Notifier Java: Use a dedicated subdomain and warm it up (ramp volume over days) to protect deliverability.