Who does what
The payment point or agent app never holds an API key. It talks to your own backend, which is the only component that calls wede with the key.
Your terminals, ATMs and agents, no new hardware
The devices that confirm payments are the ones you already operate: payment terminals, ATMs, branch kiosks, cash agents’ phones. Each is registered in wede as a device with its own offline queue, sequence numbers and envelope key, and reports through your backend, the SDKs or the frame endpoint of your own gateway. wede imposes no limit on the value of a payment and no cap on how many can be confirmed during an outage: amount limits, eligibility and approvals are rules of your bank and of the schemes and processors you work with, and they stay there. wede never holds or moves the funds of a payment and does not initiate payments: each payment is authorised, executed and settled by your bank and the schemes and processors you work with. wede carries each payment once, keeps it whole and reconciles it against your own records, your statement, the ATM journal or the terminal counter, so the books agree when connectivity returns. See Continuity, not connectivity. The snippets call the REST API through a small helper, so they run in Node.js 20 or later, browsers and React Native without extra packages:lib/wede.ts
1. Create your payment event types (one time)
Event types belong to your tenant and live in your catalog, organised by category. wede pre-loads the banking catalog (payment_offline, withdrawal_offline, deposit_offline and others under ATM and POS terminals; branch incidents under Branches and operations). Add your own types when you need them; this needs a signed-in administrator, so run it as a setup script.
setup-catalog.ts
requires_teams: false means the event is delivered and recorded, nobody is sent. wede staff roles never see your types, categories or payload.
2. Send payment confirmations from your server
When a payment point or agent app confirms a payment online, it reports it to your backend, and your backend sends the event with the API key. Use your own transaction reference as theidempotency_key: the same payment can then never become two events, whatever retries happen on the way.
server/payments.ts
202 with event_id, status: "pending" and environment. wede then delivers the event according to the connectivity of the zone and your continuity mode. Once it is delivered, its status becomes completed and wede clears the stored payload, keeping only identifiers, type, channel and lifecycle.
API key requests are limited per tenant and per minute. If you receive 429 rate_limited, wait retry_after_seconds and resend with the same idempotency_key.
3. Confirmations captured without connectivity
A payment point in a rural branch or an agent in a market keeps confirming payments when the line drops. The app records each confirmation withcapture from the helper at the moment it happens. It needs no credential and no network: it adds the capture time and the SHA-256 integrity checksum. Keep the returned object unchanged.
agent-app/capture.ts
POST /v1/sync/batch, up to 500 events per call:
server/sync.ts
POST /v1/events. If the connection drops before you get the answer, keep it in the queue: the batch returns it as duplicate if it already arrived. An app can also send the batch itself with the agent’s session token instead of going through your backend.
4. Reconcile per payment
Every event in a batch is checked on its own and gets its own result. Use them to keep your ledger and wede in step, so a payment is never counted twice:
If a batch is interrupted in flight, send the same batch again. Every payment that already reached wede comes back as
duplicate.
Accepted events follow the same delivery path as online events. GET /v1/sync/status gives the totals of your synced events by status (pending, completed, failed) and the time of the last sync.
5. Webhooks on your backend
Subscribe once with the API key. The URL must usehttps and the secret must have at least 16 characters.
server/webhooks-setup.ts
event.delivered
X-Wede-Signature is t=<unix seconds>,v1=<hex>, where hex is HMAC-SHA256 with your webhook secret over <t>.<raw body>.
server/webhooks.ts
2xx within 10 seconds. wede makes up to 3 attempts per delivery and disables a webhook after 10 consecutive failed deliveries. Deliveries carry "environment", so one endpoint can tell sandbox from production.
6. Start in the sandbox
Build and test everything with awede_test_ key first. Sandbox events are stored separately, follow the same channel decision as production, never reach a real provider and never count toward usage or billing.
metadata.zone_id set to that zone and read them back with GET /v1/events/:event_id. With a cascade configured, the event is completed through the first channel of your cascade; without one, or in store-and-forward mode, it stays pending with channel_used: "queued_offline". Lifecycle notes of simulated steps start with sandbox:. The simulation only changes the sandbox state of the zone, never its real state, and works only with a sandbox key (403 sandbox_key_required otherwise).
Also replay the same offline batch twice and check that the second run returns only duplicate results. When everything passes, replace the key with your wede_live_ key. Nothing else changes.
Optional: field agents and technicians
If you also send people to the field, for example technicians to payment terminals or agents to customers, you can add the teams, dispatch and missions module on top of the same integration. See the healthcare example for a complete dispatch flow.DORA and CBUAE alignment
wede is designed to support a financial entity’s operational resilience obligations under DORA in the EU and the business continuity and technology risk expectations of the Central Bank of the UAE. Your own ICT risk framework, contracts and controls complete it.Next steps
Offline sync
Batches, duplicates and checksums.
Connectivity
States, continuity modes and channels.
Webhook events
Every event and its data.
Security
Credentials, roles and data handling.
