Seamless wallet correctness testing
Find out what your wallet does when the same bet arrives twice.
Chipwrks sends eight adversarial sequences at a seamless wallet API — an exact replay, two amounts sharing one transaction ID, a win with no wager behind it, a rollback landing after settlement, two byte-identical bets fired genuinely in parallel — and settles most of them on the player balance, not on the HTTP status that came back. Then it reports what moved.
Independent tool. Not an accredited certification body — what that means.
What the tool actually prints
Below is unedited output from a real run, captured 16 September 2026. The three targets are Chipwrks reference wallets — one correct, one seeded with money bugs, one correct except for a single check-then-act race. Same engine, same eight checks, three different verdicts.
This console does not accept a URL and never will. It replays a stored run against our own reference wallets. Showing a recorded PASS against someone's real endpoint could get a broken wallet shipped, so the page is built so that it cannot happen. Your wallet gets tested in an engagement, against your contract, with your written authorisation — never from a marketing page.
Settled on the balance, not the status code
This is the whole design argument. A wallet that double-applies a replayed bet still answers
200 OK both times. Reading the status tells you nothing; reading the balance tells
you everything.
Status-only testing says
POST /bet → 200 OK POST /bet → 200 OK (replay) Both accepted. Looks fine.
Nothing here is wrong on its face. This is why these defects reach production.
Chipwrks says
balance 10000 → 9800 (-200) expected (-100) The replay was applied a second time.
Arithmetic, not inference. Six of the eight checks are settled this way.
The eight checks
Every one of these is a documented way a seamless wallet loses or creates money in production. Nothing here is hypothetical.
Who this is for
Operators
You own the wallet every game provider calls into. One dedupe gap is multiplied by every integration you've signed. Chipwrks tests the contract you publish, the way a provider's retry logic will actually hit it.
Aggregators
You sit between hundreds of games and dozens of wallets, and you inherit the blame for whichever side is wrong. Test your own wallet endpoints, or test an operator's before you certify the integration as live.
Studios
You're integrating into a wallet you don't control and can't see inside. Find out before launch whether a timeout-and-retry on your side turns into a double-charged wager on theirs.
How an engagement runs
You are being asked to let an outside party send adversarial traffic at a regulated money system. That deserves a precise answer, so here is the whole sequence.
-
Written authorisation first
Nothing is sent until someone with authority to grant it has authorised it in writing, with the target, the window, and the rate agreed. No exceptions, and no "just a quick look."
-
We capture your actual contract
Endpoint paths, payload shape, signing scheme, session model, currency and minor units, declared request timeout. The engine ships with a deliberately generic wallet profile, not a guess at any named vendor's — guessing a contract and running it as though it were yours is how a tester produces confident nonsense.
-
Run against a test environment
Against a staging wallet with a funded test player wherever one exists. Every request is tagged with a Chipwrks user-agent and a Chipwrks transaction-ID prefix, so your team can find every transaction we caused and reverse it.
-
Report with evidence, and questions kept as questions
Each check states what was expected, what was observed, and the balance movement that settled it. Anything that can only be resolved from inside your own records comes back as a question, never folded into a pass or fail count.
-
Optional re-run after you ship fixes
A changed wallet is a different wallet. Re-running against the fix is the one genuinely recurring piece of this, and it's priced separately rather than bundled into a subscription that has nothing to do in month two.
What this tool can't tell you
You are going to ask these questions in the first ten minutes of a call, so here they are answered in writing instead. Chipwrks reports what it actually knows, and says so plainly when it doesn't — a tool that oversells its own certainty is worse than no tool at all.
-
A concurrency PASS is weaker than a concurrency FAIL
The parallel-duplicate check fires byte-identical bets simultaneously to open a check-then-act window. If your wallet double-applies them, that's conclusive. If it doesn't, network jitter may simply have stopped the pair overlapping tightly enough. A fail is proof; a pass is evidence. We will say so in the report rather than let you read it as a guarantee.
-
A question is never reported as a failure
Some behaviours can only be settled against your ledger, not from outside. Those come back as open questions with the evidence attached. Collapsing them into a score would make the report look cleaner and mean less.
-
No verdict is issued about an endpoint that was never reached
A wrong host, a bad path, or a refused signature aborts at preflight with a stated remedy. The report says plainly that it makes no claim about the wallet. An earlier version of this engine's ancestor once scored a typo'd URL as a PASS; the abort exists because of that.
-
It is not a load test, and not a certification
Volume isn't the question — correctness is. Chipwrks is an independent testing tool, not an accredited certification body. It does not issue certificates and is not a substitute for GLI, BMM, eCOGRA, iTech Labs or any regulator-recognised lab. It finds money bugs before those bodies, or your players, find them.
-
The engine has not yet been run against a third-party production wallet
It is verified against reference wallets built to exercise it, including one deliberately seeded with defects and one with a genuine race. It has not met a WAF, a production API gateway, or real-world latency. We would rather tell you that now than have you discover it during an engagement.
Pricing
A one-time fee for the audit, and an optional fee per re-run after you've shipped fixes. No subscription, because a one-off report doesn't justify one.
There's no number on this page yet, and putting a fabricated one here would be the first dishonest thing on it. The figure depends on how many endpoints are in scope, whether a staging environment exists, and how far your contract sits from the generic profile. Ask and you'll get a real number on the call.
Request a scoping call
Tell us what you run and what you're worried about. You'll get a reply from a person who has read it.