Continuity, not connectivity

​

Two different problems

Networks keep improving. New links reach places that had no signal, and payment instruments learn to approve a transaction for a while without a line. wede welcomes every one of them, and none of them replaces wede. Coverage is a property of a network: whether a signal reaches a place at a given moment. Continuity is a property of an operation: whether it is captured, kept whole, delivered, answered and provable from the moment it happens to the moment it is cleared, whatever happened to the network, the device, the terminal or the back office in between. The first problem belongs to carriers. wede is the platform for the second.

​

What a better network does not solve

The moment connectivity comes back is when the hard questions begin. Which operations happened while the line was down? In what order? Did any of them arrive twice, over two different paths? Which were answered, by whom, and can an auditor see it a year later? What happens to an operation captured on a phone that was lost before it synced? Which were done on a network you do not control and still need to reconcile with the ones done in your core system? These questions are identical on fibre, on a cellular network, on a satellite link and on a card that approves offline. None of those answers them. wede answers them for every operation it carries:

• One identity. Every operation receives an immutable identifier and carries an idempotency key from capture. However many paths it travels, it is stored exactly once.
• Every attempt, in order. The lifecycle of an operation records each channel attempted, the channel that delivered it and the time of every step. The channel used is written on the event and sent in your webhooks.
• Integrity at the edge. Operations captured without connectivity are kept on the device with an integrity checksum. A checksum that does not match or a gap in a device sequence is not silently absorbed: it is recorded as a security incident and your administrators are alerted.
• Reconciliation with proof. What was done offline is reconciled against what was done online by rule, and the record of what happened to each operation is kept, unchanged, for review.
• An audit trail that cannot be edited. User, time, origin and outcome of every operation, immutable, for as long as your regulator requires.

See Offline-first architecture and Sync for how this is implemented.

​

Every network is a channel

wede is independent of any carrier and any transmission technology. Internet, compressed internet, SMS, voice, satellite, LoRa and local edge processing are channels in a cascade that each organisation orders for itself, zone by zone. When a new kind of link appears, direct from a satellite to a phone or anything that comes after it, it is one more channel in the cascade, one more line in the table on Offline-first architecture, not a reason to rebuild anything. Your systems keep calling the same API and receiving the same signed webhooks whatever carried the operation. This is also why wede does not compete with the networks. The more paths exist, the more wede has to choose from, and the more valuable it is to have one layer that knows which path an operation took, that it took it once, and what happened next.

​

No new hardware

The devices your people already carry are enough. The SDKs run on the phones and computers in use today, the SMS and voice paths work on any handset with a SIM, and the offline queue lives on the device itself. There is nothing to buy, install or carry for the operation to survive a dead zone, and no terminal to replace when the next generation of links arrives.

​

Your own hardware is a device too

wede is not tied to phones, tablets and computers. The API and the SDKs integrate hardware, whatever the vertical: a payment terminal, an ATM, a medical device, an EV charger, the equipment of a solar plant, a meter, a vehicle unit, an industrial controller, and any other machine that produces or confirms operations. Each is registered as a device with its own queue, sequence numbers and envelope key, and speaks to wede through the SDKs, the REST API or the frame endpoint of your own gateway. An operation captured on an ATM in a basement with no signal, or on a charger at the end of a rural line, has the same identity, the same integrity checks and the same reconciliation as one captured on a phone. wede does not sell or certify hardware; it makes the hardware you already own continuous. See Devices for how hardware is registered, one by one, from a file or from your systems.

​

Reconciled against your own records

Continuity ends when the books agree, not when the message arrives. For each organisation, wede reconciles the operations it carried against the records your systems hold: a bank statement, the journal of an ATM, the counter of a payment terminal, the log of a piece of equipment. Each operation ends as matched, unmatched or divergent, with the reason, and your systems receive the outcome by signed webhook. The rule that decides a conflict between an offline capture and an online record is the one at the core of wede: timestamps and transaction priority, applied the same way whatever the channel. See Reconciliation for the results by type of equipment and by day or hour, and the reasons behind each one.

​

The limits are yours, not ours

wede does not cap the value of an operation, does not decide which operations are allowed and does not sit between your business rules and your customer. An amount limit, an eligibility rule, a cut-off time or an approval step belongs to your organisation and to the partners you work with, and it stays there. wede carries the operation, keeps it whole, delivers it and proves what happened to it. Plan allowances cover volume and the communications you buy through wede; they never shape the operation itself. The same applies to the number of operations an outage can hold. An offline window in wede is not a counter on a card: your people keep capturing for as long as the outage lasts, and everything captured is synchronised, exactly once, when any channel returns.

​

Beyond the point of sale

A payment instrument that keeps approving for a while without a line solves one step, for one kind of operation, at one kind of terminal. The operations around it still have to continue: the agent registering a customer in the field, the clinic recording a treatment, the dispatcher sending the right team, the branch reconciling at the end of the day, the inspector filing a report from a basement. wede is the layer those operations share, across verticals and across systems, with one identity for each operation from capture to clearing. For payments specifically, wede is built so that the payment is one operation among the others: captured with the same identity, carried by the same cascade, reconciled by the same rules and auditable in the same trail as the customer onboarding before it and the delivery after it. The instrument may approve the transaction; wede is what makes the whole operation continuous and provable.

​

When your own systems are down

Continuity is also needed when the network is fine and something else is not. Operations that reach wede are held and delivered to your systems when they are reachable again, with retries and signed webhooks, so an outage in your data centre, your cloud or a partner’s platform does not become a loss in the field. Each tenant can also require a dedicated in-country instance where regulation demands it. See Security.

​

In one sentence

A network tells you whether a signal reached a place. wede tells you, for every operation, that it happened, that it happened once, how it travelled, who answered it and what it became, and keeps that true on the networks of today and on the ones that have not been built yet.