Reference wallet

Every Beexar SDK ships a working wallet in about 250 readable lines. It is not durable and it is not your ledger — it exists to show the three rules that decide whether an integration is correct, in the order they have to happen.

Node

examples/inmemory-wallet.ts

PHP

examples/InMemoryWallet.php

Go

examples/inmemory

Python

examples/inmemory_wallet.py

---

The three rules, in order

1. Dedupe on id_provider first

The platform retries, so the same id_provider will arrive twice. The second time must be invisible: return the transaction id and the balance you stored the first time. Not today’s balance. Not a fresh id.

2. Then check the tombstone

A rollback can arrive before the transaction it reverses. That is normal delivery, not an error. When the bet finally shows up, its id_provider is already tombstoned and it must be refused with api_code 409 — never applied.

3. Then apply, atomically

A /betwin request can carry several transactions. Apply them in the order given, all or none. If the third cannot be paid, the first two must not have happened — and the insufficient funds answer reports the balance as it was before the batch, because nothing moved.

lookup(id_provider)  ──found──▶  return stored id + stored balance, change nothing
      │
   not found
      ▼
tombstone(id_provider)?  ──yes──▶  api_code 409, change nothing
      │
      no
      ▼
apply, record {id_provider → your id, balance after}

Caution

In the examples a single lock stands in for your BEGIN/COMMIT. In a real wallet the dedupe read, the tombstone read and the balance update must all be in one database transaction, with id_provider under a unique index. Two transactions is a race that looks correct in development and double-credits in production — which is exactly why no Beexar SDK offers to do idempotency for you. It cannot join your transaction, so it could only pretend.

Running one

Each SDK also ships a runnable server that wires the reference wallet to an HTTP port. Point your operator’s callback URLs at it and run the Integration Test Game — it should score 29 of 29.

BEEXAR_API_SECRET=... node examples/server.js          # Node
BEEXAR_API_SECRET=... php -S 0.0.0.0:8080 examples/server.php   # PHP
BEEXAR_API_SECRET=... go run ./examples/server          # Go
BEEXAR_API_SECRET=... python examples/server.py         # Python

Conformance fixtures

The same reference wallets are driven by a shared fixture set that all four SDKs run: conformance/.

Each case carries the exact request bytes, the signature over them, the ledger before and after, and the expected response. Request bodies are compared byte for byte — several use a key order no serialiser would produce, so an implementation that re-serialises before verifying fails immediately.

They are language-neutral. If you are integrating without an SDK, point your own test suite at them and you get the same coverage the official SDKs have.