Short answer: for a startup game that emails generated reports and sends SMS alerts, choose the option with the smallest integration surface that still preserves message identity, sender compliance, and independently verifiable delivery evidence.
The report attachment is the visible feature. The accounting problem underneath is harder: one report can trigger an email, an SMS notice, a retry, and a support investigation. I treat each notification as an event with an idempotency key and an audit trail, because “sent” is not a settlement state. A provider receipt is evidence to store, not permission to mark a player paid or a prize awarded.
What should a startup app compare for SMS sender registration and delivery receipts?
Start with a decision record. Keep the comparison about integration effort, not a headline price.
| Check | Minimum evidence | Failure boundary | Integration question |
|---|---|---|---|
| Per-message accounting | A stable request ID and a recorded unit count | Long Unicode text can segment into multiple SMS parts | Can the ledger reconcile provider units to one game event? |
| Sender registration | Country-specific sender type and approval state | US and EU routes can require different identities | Is registration data versioned with the deployment? |
| Delivery receipts | Raw status, timestamp, and provider message ID | A receipt is not proof that a handset displayed text | Can support replay the exact status transition? |
| Polling | Cursor or time window plus backoff | Re-reading a window can duplicate updates | Is receipt ingestion idempotent? |
| Attachment email | MIME filename, size, and checksum | A successful upload does not prove inbox delivery | Can the report event link email and SMS records? |
| Operations | Structured logs and a dead-letter path | Silent drops become unreconcilable gaps | Who owns replay after a deploy? |
The table exposes the useful trade-off: a simpler API can reduce glue code, but a black-box status model increases reconciliation work. Your mileage may vary across countries; carrier rules and sender registration change independently of application releases.
1. How can message-part counting protect a game report ledger?
SMS length is not a single universal limit. GSM-7 and UCS-2 use different character budgets, and concatenated messages consume more than one segment. A report alert containing a curly quote, an emoji, or a player name outside GSM-7 can therefore create a different per-message charge than the same alert in plain ASCII. The encoding and segmentation reference in References gives a useful test case, not a pricing promise.
Persist the normalized text, encoding decision, segment estimate, and final provider-reported unit count. I once designed a ledger that stored only notification_id; a retry looked harmless until reconciliation found two unit charges for one report. The fix was boring: a unique key on (event_id, channel, attempt) and an append-only adjustment record. That key also made a late carrier correction auditable: the original unit count stayed immutable, the correction became a new row, and the nightly reconciliation could explain both rows to finance without guessing which retry had actually reached a handset.
Boring wins.
Sender registration belongs in the same decision record.
Sender identity is part of the deployable artifact. A US long-code, toll-free sender, or an EU alphanumeric sender may have different registration and reply semantics. Do not hide that choice in an environment variable that nobody reviews. Store country, sender type, approval reference, and effective date beside the routing rule, then make a deployment fail closed when a required approval is absent.
This is a boundary, not a retry problem. Retrying an unregistered sender only multiplies uncertainty and can create duplicate alerts. A startup can begin with fewer destinations and a narrower sender policy, provided the product clearly labels unsupported countries instead of pretending that one identity works everywhere.
2. How should receipts and polling preserve exactly-once effects?
Define the states your game actually needs: accepted, queued, sent, delivered, expired, and failed. Map external statuses into that vocabulary, retain the raw value, and reject a transition that would move a terminal state backward. Delivery receipts should include the message ID, event ID, observed time, and source payload hash.
The critical path can remain small. This Go sketch uses generic HTTP boundaries and leaves authentication and transport policy to the application:
package notify
import (
"bytes"
"context"
"encoding/json"
"fmt"
"net/http"
)
type Alert struct {
EventID string `json:"event_id"`
To string `json:"to"`
Body string `json:"body"`
}
type Receipt struct {
MessageID string `json:"message_id"`
Status string `json:"status"`
}
func Send(ctx context.Context, endpoint string, a Alert) (Receipt, error) {
payload, err := json.Marshal(a)
if err != nil {
return Receipt{}, err
}
req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, bytes.NewReader(payload))
if err != nil {
return Receipt{}, err
}
req.Header.Set("Content-Type", "application/json")
resp, err := http.DefaultClient.Do(req)
if err != nil {
return Receipt{}, err
}
defer resp.Body.Close()
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return Receipt{}, fmt.Errorf("notification submit status %d", resp.StatusCode)
}
var r Receipt
if err := json.NewDecoder(resp.Body).Decode(&r); err != nil {
return Receipt{}, err
}
return r, nil
}
In production, bytesReader is a small io.Reader adapter, and the request carries an idempotency key derived from EventID; the example keeps that policy visible without pretending an external endpoint has a particular schema. Never infer delivery from an HTTP 200 alone.
Polling is reasonable when inbound webhooks cannot be exposed, but it needs a durable cursor and overlap. Read a short time window, overlap the next poll by a few minutes, and deduplicate on the provider message ID. If the API offers neither a cursor nor stable IDs, the integration is not simple; it has merely moved complexity into your database.
Record poll start, poll end, item count, and the highest observed cursor. A failed poll must be retried without advancing that cursor. Receipt ingestion should be exactly-once in effect, even when transport is at-least-once. That distinction is where most “cheapest” designs spend their hidden engineering hours.
3. How can an app join email attachments to an SMS alert event?
Generate the report once, hash the bytes, and create an event row before sending either channel. The email record stores filename, MIME type, size, and checksum; the SMS record stores the concise status link or reference. A support operator can then answer “which report did this alert describe?” without searching logs across two systems.
The email transport has its own limits and policies. The email service documentation linked in References covers sender verification and message construction, while the SMS route supplies the carrier-specific receipt contract. Keep those contracts separate in code and in the audit schema.
4. Which shortcut is acceptable only for a disposable playtest?
The rejected option is a single fire-and-forget call followed by a dashboard screenshot. It is acceptable for a disposable internal playtest where no player action depends on the message. It is not suitable when a tournament report, payout notice, or compliance record must be provable months later. In that case, retain the event ledger, receipt history, and replay procedure even if the notification API itself is delightfully small.
Integration effort is therefore measured in boundaries: sender approval, segment accounting, receipt identity, polling semantics, and attachment linkage. Select the service whose documented behavior lets your team implement those boundaries with the fewest bespoke adapters, then test US and EU routes separately before launch.
Top comments (0)