Supplier evaluation checklist

How to use this

• Send the same questions to every supplier, in writing, before the first call rather than after it.
• Record who answers in writing, who will only answer on a call, and who does not answer at all. A supplier who will not answer in writing has answered.
• Ask us these too. They were written to be asked of us, and the section at the end lists the ones where our answer is the weakest.

Nothing here is downloadable, deliberately. A gated document would make a procurement question into a lead form, and an ungated file would be this page with worse accessibility. Copy what you need.

The model and the money

• What is the commercial shape on each route, and what is the share taken on?
• Is there a minimum, and what is it?
• What is excluded from the price that a first-time buyer assumes is included?
• Who bears the cost of a payout, per payout?
• What does the first invoice actually contain?
• What changes commercially if volume doubles, or halves?
• Is there a one-off fee, and what does it buy that the running fee does not?

Compliance and access

• Do you determine a player's location, or enforce against one I give you?
• If I send you the wrong state, what happens, and what does your record show?
• Can registration, play and redemption be set independently per state?
• How fast does a state change take effect, and does it need a release on my side?
• Who performs identity verification, and who enforces the gate that requires it?
• What monitoring exists, is it a system or a person, and what does it produce?
• What would you produce if a regulator asked tomorrow?
• Does anything in your chain reach me as a supplier rather than as an operator?

Integration and operations

• Who is wallet of record on each route?
• Is the API versioned, and what is the deprecation policy?
• What happens to a player mid-round when your service goes down?
• How is a failed or duplicated call made safe?
• What does a sandbox reproduce, and what does it not?
• How long does an integration take, measured from your side?
• Who is reachable at two in the morning, and what can that person actually do?
• What is the uptime commitment, and what happens when it is missed?

Content

• Who holds the certificate for the titles you are offering?
• How is your catalogue counted, and when was it last counted?
• Does a title behave identically in both currency contexts, and can you show it?
• Which studios did you integrate yourself, and which arrive through somebody else?
• How long does a new studio take to reach my lobby?
• If a studio leaves, what notice do I get and what happens to titles in play?
• Who do I describe a misbehaving title to, and who do they describe it to?

Commercial and exit

• What exactly can I export, in what format, and how far back?
• How much notice, and written where?
• Who owns the front-end code if we part?
• What happens to redemptions in flight on the last day?
• Does verification status come with us?
• What happens to player balances during a move?
• Have you actually migrated an operator from another platform, and what went wrong?
• What is agreed at signing that only matters at leaving?

The questions we answer badly

The questions we answer badly. Seven of the questions above have answers from us that a buyer may not like. They are collected here rather than distributed where they are easiest to miss, and each one links the page that sets it out in full.

• Who runs my payment rails?Nobody on our side. We supply no acquiring, no ACH, no open banking and no payout execution on either route. The single exception is a crypto payout rail on the managed platform, and the reason it can exist is that it needs no merchant account.What we do and do not supply in payments
• Who performs identity verification?You do, on both routes, with your own provider. We never perform a check, never see a document and never decide whether somebody is who they say they are. On the managed platform the gate that requires the check is ours; the check never is.Who verifies, and when
• Do you determine where a player is?No. You determine the state by whatever method you choose and pass it to us. There is no IP lookup, no device check and no specialist vendor on our side of the line.Where the per-state rules are set and enforced
• What monitoring do you provide?People, not a system. There is no rules engine and no automated alerting; our team sees activity and tells the operator when something looks wrong. It is a courtesy backstop and it is not the thing to point a regulator at.What the monitoring is, in its own words
• How long do you keep the redemption audit record?Sixty days on the managed platform. On an API integration we never see the redemption at all, so there is no record of ours to keep — the one that matters is yours.What the record contains and who holds it
• Do we own the front-end code?Not by default. Where we built it, it is licensed to you for the life of the engagement rather than assigned. A source handover can be negotiated separately; it is not free and it is not the standard arrangement.What a delivered launch includes and does not
• Have you migrated an operator from another platform?No. One operator arrived from another provider and started fresh — new accounts, new balances, nothing carried across. That is an onboarding rather than a migration, and we would rather say so than let the word do work it has not earned.What a cutover requires, and what we have not done

Where each of these comes from

One link per group. The questions are here; the reasoning stays on the page that owns it, which is what keeps this a document you can send rather than a second copy of the site.

• The model and the moneyWhat each route is priced as, and what is excluded
• Compliance and accessWhat the model rests on, and what a regulator can do without a statute
• Integration and operationsThe integration reference
• ContentWhat sits between a studio and your lobby
• Commercial and exitWhat leaving a platform involves, and our own answers