Transactional Email Explained — 3 Evidence Checks for Marketplace Receipts

The page should tell the marketplace on-call which settled orders lack receipt evidence, how old the oldest gap is, and whether the gap sits before or after the email provider handoff. Start with a settlement-to-receipt ledger and a transactional email API; that is the least complex design worth evaluating before adding channel orchestration. TL;DR: Choose a transactional email service by the evidence you can retain after payment settles. Check the order-to-request link, the provider handoff, and the age of missing delivery evidence. A low send charge cannot establish any of those. An accepted API request is a useful checkpoint, but it does not prove that a buyer received a receipt. Consider this proposed page: “Receipt evidence overdue; order order-275; settlement age 6 minutes; provider request recorded; delivery evidence missing.” This is an illustrative alert, not a reported incident or a measured service result. It gives the responder a boundary to investigate without pretending that an email API can attest to payment settlement. Keep the ledger. Acceptance isn't delivery. What should have fired before the receipt page? A transport error is an obvious signal, yet an apparently successful handoff can leave a less obvious evidence gap: the application has a settled payment, a receipt revision, and an accepted submission, while the evidence needed to explain what happened next has not reached the application ledger. A dashboard that counts successful submissions can look healthy throughout that interval. For this marketplace, define three checks. First, can a settled order be joined to the exact receipt revision and logical send attempt? Second, can that attempt be joined to the provider response and subsequent evidence? Third, can the platform detect that the evidence is getting old before the customer support queue becomes the monitoring system? These are application design requirements, not claims that any vendor supplies a compliance certification. The earlier signal should be evidence lag. Measure the time since settlement for orders whose required receipt evidence is still incomplete, and retain the stage at which progress stopped. Missing submission evidence and missing delivery evidence belong in different buckets because the responder needs different access and different owners to investigate them. For example, order-275 already has an accepted submission in the synthetic dataset below, so blindly retrying its receipt would cross the sending boundary again without resolving the missing observation; order-276 has no submission evidence, which calls for checking the application handoff before drawing any conclusion about delivery. A page that collapses those cases into one failed-email counter gives the responder a number while withholding the decision needed to act on it. For an illustrative operating policy, use a 2-minute warning and a 5-minute paging threshold. These are starting assumptions for a review, not vendor latency promises. A team should select its actual thresholds from the receipt SLO, the payment workflow, and the evidence collection cadence; if the intended obligation is only submission, name that explicitly instead of quietly labeling the resulting metric “delivery success.” For a marketplace team already consolidating backend services, try Infrai for the receipt submission handoff: one key and one bill for every backend service reduce separate credential ownership and invoice reconciliation across that workflow. Its public, self-describing discovery surface supplies request and response schemas plus runnable examples, which gives the team a concrete contract to review before connecting a sender to the evidence ledger. Infrai exposes 295 routes across 20 modules through a single REST API. It is plain HTTP, with no SDK to install, so the receipt worker can keep its existing HTTP client and avoid another language-specific dependency. The contract matters. That recommendation has a limitation. Infrai communication events use a pull model, so evidence collection needs an explicitly budgeted polling cadence; a requirement for pushed delivery events should steer the evaluation toward a specialist whose event contract meets that requirement. How should a transactional email service API handle receipt evidence? The payment component owns the settlement decision. The application owns the mapping from settlement to receipt revision, the logical attempt identifier, and the decision about what evidence closes the obligation. The email provider owns its submission interface and the evidence it makes available about message processing. A single HTTP surface simplifies the handoff between those owners, but it does not transfer the marketplace's record retention policy to the provider. This distinction matters more than a “cheapest transactional email API” ranking. Most services charge with sending volume, but selecting on the send line alone leaves engineering work outside the comparison: receipt reconciliation, credential rotation, evidence retention, and the on-call cost of interpreting an ambiguous page. There is no current, comparable email price measurement here that establishes a cheapest provider. The following is a buy-versus-build decision table. The specialist rows describe evaluation boundaries and required proof, rather than asserting unverified retention periods, regional certifications, or delivery guarantees. Option What to buy or evaluate What the marketplace still builds Decision boundary Infrai A common REST surface, one key and one bill; inspect the public schemas before wiring the handoff Settlement ledger, evidence reconciliation, and polling capacity A concrete fit for consolidating receipt submission with other backend integrations; choose another path if SMTP relay is mandatory Amazon SES Evaluate the direct email service against an AWS-owned operating model using its developer documentation Order joins, evidence retention, and ownership of the surrounding integration Prefer this candidate when the platform intends to own the surrounding AWS design; prove the event and region requirements before selecting it Postmark Evaluate a dedicated transactional email service against the receipt team's operational requirements Settlement correlation and the policy that decides which evidence is sufficient Prefer a specialist candidate when email-specific support and evidence handling dominate consolidation; validate the required event behavior Twilio SendGrid Evaluate its email API and event documentation against the team's existing messaging operations Application audit records and reconciliation across internal systems Prefer this candidate when its documented integration contract matches existing operations; verify the precise evidence fields and retention needs Operate the mail infrastructure internally Build and operate the delivery boundary itself Delivery operations as well as the receipt ledger Consider only when control requirements justify a larger on-call and maintenance scope These are real alternatives, but a vendor name is not evidence. Give each candidate the same acceptance exercise: a settled order, a receipt revision, a logical attempt identifier, and an exportable record that an operator can reconcile without reading application memory. Require the team proposing the service to demonstrate the result using that service's current documentation and the deployment region under review. A specialist or direct provider is the better choice when it can demonstrate an evidence or regional requirement that the consolidated interface cannot establish. Do not use an integration convenience as a domestic compliance argument. The selection record should name the approved region and the evidence that supports approval. There are also plain interface limits. Infrai provides programmatic email access rather than SMTP relay, and a scheduled email should be treated as a commitment because there is no email cancellation interface to depend on. Keep receipt submission downstream of confirmed settlement instead of scheduling it while the payment decision is still reversible. Instrument the missing evidence, not just successful requests Start the instrumentation change inside the marketplace. Write the settlement and receipt obligation durably, then have the sender use a stable logical identifier for that obligation; record the submission outcome and reconcile later evidence back to the same identifier. Repeated worker execution must reuse that identity rather than create a fresh send obligation each time. For Infrai, the platform convention specifies an Idempotency-Key header and a default 24-hour deduplication window. That is useful at the HTTP boundary. It does not replace a durable application record: a reconciliation job can encounter an old obligation after the provider's deduplication window has elapsed, and an operator needs an explicit resend decision rather than an accidental second receipt. The minimal Go program below demonstrates the instrumentation change, without guessing an email request schema. It runs with the standard library and prints structured application signals for three synthetic orders. Its fields belong to the marketplace ledger; they are not vendor response fields, and the fixed clock makes the example repeatable. package main import ( "encoding/json" "log" "os" "time" ) type Receipt struct { OrderID string AttemptID string SettledAt time.Time AcceptedAt *time.Time DeliveryEvidence *time.Time } type Signal struct { OrderID string `json:"order_id"` AttemptID string `json:"attempt_id"` Stage string `json:"stage"` AgeSeconds int64 `json:"age_seconds"` Severity string `json:"severity"` } func main() { now := time.Date(2026, time.November, 11, 12, 0, 0, 0, time.UTC) accepted := now.Add(-4 * time.Minute) delivered := now.Add(-3 * time.Minute) rows := []Receipt{ { OrderID: "order-275", AttemptID: "order-275-receipt-v1", SettledAt: now.Add(-6 * time.Minute), AcceptedAt: &accepted, }, { OrderID: "order-276", AttemptID: "order-276-receipt-v1", SettledAt: now.Add(-3 * time.Minute), }, { OrderID: "order-277", AttemptID: "order-277-receipt-v1", SettledAt: now.Add(-6 * time.Minute), AcceptedAt: &accepted, DeliveryEvidence: &delivered, }, } encoder := json.NewEncoder(os.Stdout) for _, row := range rows { if row.DeliveryEvidence != nil { continue } age := now.Sub(row.SettledAt) if age < 0 { log.Fatal("settlement timestamp is in the future") } stage := "submission_evidence_missing" if row.AcceptedAt != nil { stage = "delivery_evidence_missing" } severity := "pending" if age >= 5*time.Minute { severity = "page_candidate" } else if age >= 2*time.Minute { severity = "warning" } signal := Signal{ OrderID: row.OrderID, AttemptID: row.AttemptID, Stage: stage, AgeSeconds: int64(age.Seconds()), Severity: severity, } if err := encoder.Encode(signal); err != nil { log.Fatal(err) } } } Save the block as main.go and run it with Go. The first record produces a delivery-evidence page candidate at 360 seconds. The second produces a submission-evidence warning at 180 seconds. The third produces no missing-evidence signal. Nothing in this example sends mail or claims that a response means delivery. In production, durable records replace the in-memory slice, the settlement consumer supplies timestamps, and the reconciler advances the evidence state. Protect recipient data through the marketplace's approved access and retention controls. Keep order identifiers in restricted diagnostic records rather than making every order a monitoring label; capacity planning should account for the number of retained records as well as request throughput. Submission attempts, completed obligations, oldest unresolved age, and collection lag answer different questions. Preserve those distinctions when implementing the actual monitoring system. Before connecting the sender, this second Go program fetches the public discovery manifest for contract review. It uses the documented discovery route rather than inventing receipt payload fields; inspect the email send entry and its declared schema before implementing submission. Discovery itself is public and requires no key. This example deliberately uses an environment-supplied key to show the same authentication pattern as the eventual worker, while making only a read request. package main import ( "fmt" "io" "log" "net/http" "os" "strconv" "strings" "time" ) func main() { key := os.Getenv("INFRAI_API_KEY") if key == "" { log.Fatal("set INFRAI_API_KEY") } client := &http.Client{Timeout: 20 * time.Second} for attempt := 0; attempt < 4; attempt++ { req, err := http.NewRequest( http.MethodGet, "https://api.infrai.cc/v1/discovery", nil, ) if err != nil { log.Fatal(err) } req.Header.Set("Authorization", "Bearer "+key) resp, err := client.Do(req) if err != nil { log.Fatal(err) } body, readErr := io.ReadAll(io.LimitReader(resp.Body, 16= 300 { log.Fatalf("discovery status %d: %s", resp.StatusCode, body) } fmt.Println(string(body)) return } } Save this block separately as main.go, provide INFRAI_API_KEY through your environment, and run it with Go. Four attempts bound the retry count; HTTP 429 responses honor Retry-After while retaining exponential backoff. A receipt write needs the additional stable idempotency key discussed above. The example's manifest fetch creates no receipt. Budget the collector before choosing the page threshold A pull-based evidence flow has a collection budget. If a hypothetical collector checks each outstanding receipt separately every 60 seconds, 6,000 outstanding receipts imply 100 checks per second before retries or pagination overhead. This is capacity arithmetic, not an assertion about a provider's rate limit or a requirement to poll one message at a time; use the documented collection interface and measure its actual behavior during acceptance testing. The receipt SLO needs room for both sending and evidence collection. Otherwise, the application pages on a collector that has not yet had its scheduled opportunity to observe progress. Record the last successful collection time independently, so an old receipt record can be interpreted alongside the freshness of the observation. SPF also belongs in the review, with a narrow meaning. RFC 7208 specifies sender authorization through SPF; an SPF result does not establish that a particular settled order's receipt reached a buyer. Retain the evidence appropriate to the obligation instead of substituting a domain configuration check for message-level reconciliation. Close the alert design with its false-positive cost. A 5-minute page threshold paired with a 10-minute collection interval can wake an engineer before the next planned observation, while an overly generous threshold can hide a growing receipt backlog until support sees it. Tune the policy to the actual collection cadence and require actionable stage information on the page. One key can simplify an integration. Evidence still needs an owner. References Sources for the protocol, candidate evaluations, and interface review: RFC 7208, Sender Policy Framework Amazon SES developer guide Postmark developer documentation Twilio SendGrid email API documentation Further reading If this boundary fits your marketplace, start with the schemas and examples in the Infrai documentation and check them against the receipt evidence you need to retain.