WASL — architecture and integrations

The diagram chapter 11 asks for: which systems WASL talks to, what flows between them, and which system is the source of truth for each kind of data. Draft for discussion, not a commitment — several arrows depend on answers we do not have yet.

How the systems sit together

Exact is drawn dashed because the RFP indicates no direct WASL–Exact integration is needed. That is on the question list to confirm.

Who owns which truth

Chapter 11 asks this to be settled before implementation. Our proposal:

Data	Source of truth	WASL holds
Products, business prices, stock	Brincr	A cached copy for display, refreshed on a schedule
Partner as a customer record	Brincr	The link between WASL organisation and Brincr customer
Partner organisation, locations, users	WASL	The whole record — these do not exist elsewhere
B2B order, operationally	Brincr	Its own order ID, the Brincr reference, and status
B2B order, commercially	WASL	What was ordered, the rules applied, credit used
Prepaid payment	MultiSafepay	Payment status and provider reference only
D2C orders and consumer personal data	WooCommerce	Order reference and value for attribution — no personal data
Consumer interactions and feedback	WASL	The whole record
Partner Credit	WASL	The full ledger, append-only
Financial administration	Exact	Nothing

How failures are handled

Chapter 5 requires the order flow to be idempotent and chapter 11 requires adequate error handling, logging and retries. Concretely:

Every order carries an idempotency key. Submitting the same order twice — a double click, a retried request, a duplicated webhook — returns the existing order rather than creating a second one.
Payment is confirmed by webhook, never by the browser. A guest closing the tab cannot leave an order paid but unsent, or sent but unpaid.
Outbound calls to Brincr are queued and retried with backoff. A failure leaves the order in a visible state an internal user can reprocess, not in silence.
Every integration call is logged with its reference, so an order can be traced end to end in either system.

What this diagram assumes

Three arrows depend on answers we do not have yet, and each could change the shape above:

Brincr's API. Whether it pushes webhooks or must be polled changes how fresh prices and stock can be, and how much work the integration is.
Attribution mechanism. Whether the webshop is on the same domain, and whether attribution must survive a refused cookie banner, decides how the reference is carried.
Exact. Drawn as out of scope on the RFP's own indication. If credit has to appear on the financial side as something other than a line on the Brincr order, that changes.

Back to the walkthrough