The Dollr Open API does not expose inbound HTTP webhooks for payment events. Choose a pattern below based on your architecture.
Option comparison
| Pattern | Best for | Server load | Complexity |
|---|
| Hosted checkout + server verify | Payment links, simple stores | Low | Low |
| Poll execution status | API-embedded checkout, few payments | Medium | Low |
| Poll source status | Hosted checkout success page | Low | Low |
| Realtime keys (Supabase) | Live checkout UI in browser | Low server, client subscribes | Medium |
Pattern 1 — Hosted checkout (recommended)
Customer pays on Dollr’s page. Your backend verifies before fulfilling:
1. Create hosted checkout → redirect to url
2. Customer lands on success_url
3. YOUR SERVER calls GET /v1/status/source?source_type=INVOICE&source_id={id}
4. Fulfill only when status === "PAID"
Never fulfill an order based on success_url redirect alone. The customer can close the tab before payment completes.
Pattern 2 — Poll execution status (API-embedded)
After POST /v1/executions/collection:
1. Store reference_id in your DB before the HTTP call
2. Poll GET /v1/status/collection/{reference_id} every 2–5s
3. Stop on COMPLETED or FAILED
4. Back off during PROCESSING (MoMo can take several minutes)
Pattern 3 — Realtime keys (browser)
For live UI updates while the customer waits on your checkout page:
POST /v1/realtime-keys/collection → short-lived access_token- Subscribe via Supabase Realtime (see Realtime status)
- Fall back to polling if the connection drops
Your backend should still verify with GET /v1/status/collection/{reference_id} before fulfilling — treat realtime events as UX hints, not the sole source of truth.
Pattern 4 — Cron reconciliation
For high volume or missed callbacks:
Every N minutes:
SELECT pending orders FROM your_db
For each: GET /v1/status/source or /v1/status/collection/{reference_id}
Update order state
Laravel / framework note
Use polling or realtime keys — not webhooks. If your framework guide mentions webhooks, follow this page instead.
