DEV Community: Lora Henley

How to Fact-Check a Payment Provider's Sales Deck Before You Sign

Lora Henley — Tue, 11 Aug 2026 09:10:41 +0000

A high-risk PSP pitch is a well-rehearsed document. It has a rate card with a headline percentage, a map with a lot of countries shaded in, a line about settlement, and a licence badge somewhere near the footer. Every element is technically a claim, and almost none of them are written in a way that survives contact with a contract.

This is not usually fraud. It is a sales artifact produced by a sales team, describing best-case terms for an ideal merchant in the friendliest of the provider's acquiring relationships. The gap between that and what you get shows up three months in, when your effective rate is a point higher than quoted, your rolling reserve is 10% instead of 5%, and settlement moved from T+3 to T+7 "temporarily" after a chargeback spike.

The good news is that most of the deck can be checked in an afternoon, using public records and a handful of carefully worded emails. Here is how to do it, line by line.

Start by converting the deck into a list of testable claims

Open the deck and write down every factual assertion in one column. Not the adjectives — the assertions. Typical output:

"1.9% + €0.20 for EU cards"
"Coverage in 40+ countries"
"T+3 settlement"
"Licensed EMI"
"5% rolling reserve, 180 days"
"Direct acquiring relationships"
"No hidden fees"

Now add three columns: how I verify this, what the evidence says, and is it in the contract. That third column is the one that matters at signature. A claim that cannot make it into the agreement is a claim the provider does not intend to be held to.

Most of what follows is about filling in the middle column.

The rate card: find the effective rate, not the headline rate

The headline percentage is the cheapest card type in the cheapest region under the friendliest interchange assumption. It is real, in the sense that some transaction somewhere will price at that number. It is not what you will pay.

Ask for the full fee schedule in writing, and specifically for these items, because they are the ones that go missing from decks:

Rate by card type and region — consumer vs commercial, domestic vs cross-border, EEA vs non-EEA
The scheme fee and interchange pass-through treatment (blended or IC++, and if blended, what happens when interchange rises)
Chargeback fee, representment fee, and whether you are charged for chargebacks you win
Refund fee, and whether the original processing fee is returned on refund
Monthly minimum, gateway fee, per-transaction fee, PCI fee, setup fee, account maintenance fee
FX markup on settlement into your currency
Payout fee per settlement batch and per bank account

Then do the arithmetic on your own last 90 days of transaction data, not on a hypothetical basket. Take your actual card mix, your actual refund rate, your actual chargeback count, and price it under their schedule. That number is your effective rate. Compare it against your current provider's effective rate calculated the same way. In high-risk, the difference between headline and effective is frequently large enough to reverse the ranking of two providers.

If the provider will not give you a full fee schedule before you sign, that is itself a finding. Write it down.

The licence badge: check which entity holds it, and which entity signs your contract

This is the single highest-value check in the whole process, and the one merchants skip most often.

PSP licensing verification is a two-step process. First, take the licence number or the entity name from the deck and look it up in the register of the regulator that issued it — the FCA register in the UK, the relevant national register for EEA EMIs and PIs, MAS, and so on. Confirm four things: the entity exists on the register, the permission covers what you are buying (payment services, e-money issuance, safeguarding), the status is active rather than lapsed or restricted, and the registered address matches what the provider tells you.

Second — and this is the step that matters — get a draft of the merchant agreement and read the counterparty name on page one. Very often it is not the licensed entity. It is a sales or technology company in another jurisdiction, sometimes an offshore holding entity, contracting with you for "services" while the regulated entity sits behind it holding the funds and the permission you were shown.

That structure is not automatically bad; layered corporate groups are normal in payments. But it changes your position materially. If the entity you contract with is not the regulated one, then safeguarding rules, complaints procedures and regulatory recourse may not attach to your relationship at all. When funds are held and you escalate, you need to know which company is actually holding them and which regulator, if any, will take your complaint.

So write down both names. Then pull corporate records for each: incorporation date, registered office, directors, shareholders, filed accounts if the jurisdiction requires them. A processor pitching you on a decade of experience while its contracting entity was incorporated eight months ago is telling you something the deck did not.

Coverage claims: ask which acquirer, in which country, for which MCC

"Coverage in 40+ countries" usually means the group can, in principle, route transactions to acquirers in those countries. It does not mean your MCC is approved in those countries, and in high-risk verticals the MCC is the whole question.

The precise question to ask is: for MCC [yours], in [country], which acquiring bank will my traffic route to, and is my business type already approved there or does it require a new underwriting submission? Ask for the same answer for each of your top three markets.

You will get one of three responses. A specific acquirer name and a confirmation of existing approval — good, and now verifiable. A vague answer about "our banking partners" — this means the relationship does not yet exist for your vertical. Or a promise to "get you approved" — which means you are the underwriting submission, and the timeline is theirs, not yours.

Also ask what happens when an acquirer drops your MCC. Every high-risk merchant experiences this eventually. The answer you want describes redundancy: a second approved acquirer, and a stated migration process. The answer you do not want is silence.

Settlement terms, reserves, and the fund-hold question

Settlement terms in a deck are almost always stated as a single figure — T+3, T+7 — with no conditions attached. The contract will attach conditions. Find them.

The four questions to put in writing:

Under what circumstances can settlement be delayed or suspended unilaterally, and with what notice?
Can the rolling reserve percentage or the hold period be changed during the term, and if so, by whose decision and with what notice?
What happens to reserved funds on termination — what is the release schedule, and does it start at termination or at the end of the chargeback window?
In the last 24 months, has this provider extended holds or raised reserves across a merchant category?

Question four will rarely be answered honestly, which is why the fund-hold track record has to come from outside the provider. Merchants who have had funds held tend to talk about it; the difficulty is that the accounts are scattered across forums, chat groups and payment service provider reviews of wildly varying reliability, and a lot of the directory-style sites that aggregate them are ranked by who paid for placement. PSP Trust exists to put that in one place — an independent directory that publishes what a provider states alongside what verification shows, covering licensing, corporate records, live site vitals and merchant-reported incidents that are classified and published only after human review, across 54 providers and 133 countries.

Live vitals as a proxy for operational care

You cannot audit a PSP's internal engineering from the outside. You can look at the surfaces they do expose, and treat them as a signal.

Check the SSL certificate on the merchant dashboard and the API endpoint: issuer, expiry, whether the chain is complete, whether TLS versions and ciphers are current. Check the domain: registration date, registrar, expiry, whether it renews annually at the last minute, whether the WHOIS record is consistent with the corporate entity you looked up. Check whether the status page exists and has real incident history, or whether it is a green square that has never changed.

None of these prove anything on its own. A lapsed certificate on a marketing site is trivial. A lapsed certificate on the endpoint your checkout posts to, on a company asking you to trust it with settlement, is a statement about internal process. Companies that let those things slip are usually letting other things slip too, and the other things are the ones that hold your money.

Put the claims back in writing

The mechanism that converts a sales claim into an obligation is email. Not a call, not a demo, not a Slack channel with your account manager. Email, from you, restating the claim in their words, asking for confirmation.

Use language like this:

Following our call, I want to confirm my understanding before we proceed to contract.

Pricing for EU consumer cards is 1.9% + €0.20, on an IC++ basis, with no additional scheme fee markup. Please confirm, and send the full fee schedule including chargeback, refund, FX and payout fees.

Settlement is T+3 from capture. Please confirm the conditions under which settlement may be delayed, and the notice period.

Rolling reserve is 5% over 180 days and is fixed for the initial term. Please confirm whether this can be varied during the term, and by what process.

Our contracting counterparty is [Entity A]. The licence referenced in your materials is held by [Entity B]. Please confirm the relationship between the two entities and which one holds and safeguards merchant funds.

For MCC [xxxx] in [country], traffic routes to [acquirer]. Please confirm this approval is already in place.

If any of the above is inaccurate, please correct it in reply.

That last line does the work. A sales representative who will not correct an inaccuracy in writing has told you the claim was not meant literally. And when you later end up in a dispute, a thread where the provider confirmed specific terms is worth considerably more than your recollection of a call.

The one-page pre-signature audit

Run this before you sign anything. It takes an afternoon.

Entity and licence

[ ] Licence number located on the issuing regulator's public register
[ ] Permissions cover the service you are buying; status active
[ ] Contracting entity on the draft agreement identified by name
[ ] Relationship between contracting entity and licensed entity confirmed in writing
[ ] Corporate records pulled for both: incorporation date, directors, registered office

Money

[ ] Full written fee schedule received
[ ] Effective rate calculated against your own last 90 days of transactions
[ ] Reserve percentage, hold period and release schedule confirmed in writing
[ ] Settlement timing plus the conditions under which it can change, in writing
[ ] Termination clause read: notice period, reserve release, data export

Coverage

[ ] Named acquirer per key market, with MCC approval status confirmed
[ ] Redundancy answer received for acquirer loss

Operational signals

[ ] SSL and domain vitals checked on the dashboard and API endpoints
[ ] Status page and incident history reviewed
[ ] Independent merchant reports and fund-hold history reviewed from a source that does not sell placement

Paper trail

[ ] Confirmation email sent restating every material claim
[ ] Reply received and archived
[ ] Every confirmed term traced to a clause in the agreement

Any unchecked box is not a dealbreaker by itself. Three unchecked boxes in the money section, on a provider that will be holding six figures of your revenue in reserve, is a decision you are making without information you could have had.

Why Most iGaming Platforms Have Slow Withdrawals (And How We Architected Around It)

Lora Henley — Tue, 05 May 2026 08:44:48 +0000

If you've ever wondered why most online gaming platforms take 3–7 business days to process a withdrawal while your bank app moves money in seconds, the answer isn't regulation. It isn't even a fraud risk, mostly.

It's that the average iGaming backend is a stack of legacy services duct-taped to payment processors from 2014, running synchronous flows with manual review queues bolted onto them. The technology to do this in minutes has existed for years. The architect will haven't.

I've been working on the payments layer at 6ense - a new iGaming platform licensed by the Curaçao GCB - and I want to walk through how we approached the withdrawal pipeline, because it's a more interesting problem than it gets credit for in most engineering discussions.

This post is about the architecture, not the product. If you build payment systems, fintech, or anything where "fast and safe" pull in opposite directions, the patterns here generalize.

The Core Tension

Withdrawals in iGaming have to satisfy three things that fight each other:

Speed - players expect their money quickly. Slow payouts are the single biggest trust signal in the category.
Compliance - KYC checks, AML thresholds, sanctions screening, jurisdiction rules.
Fraud prevention - multi-accounting, bonus abuse, stolen-card top-ups followed by withdrawal to a clean wallet.

The legacy approach optimizes for #2 and #3 by making everything synchronous and human-reviewed. Player requests withdrawal → sits in queue → operator reviews → payment processor called → funds eventually leave. Total elapsed time: days.

The modern approach decomposes the problem. Each concern runs in parallel, scores independently, and converges on a decision. If the decision is "approve," money moves immediately. If it's "review," it goes to a human. If it's "decline," the player gets a clear reason.

The architecture looks roughly like this:

                 ┌─────────────────┐
                 │ Withdrawal      │
                 │ Request (API)   │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │ State Machine   │  ← single source of truth
                 │ (PENDING)       │
                 └────────┬────────┘
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
    ┌──────────┐    ┌──────────┐    ┌──────────┐
    │ Risk     │    │ Compliance│   │ Liquidity│
    │ Scoring  │    │ Engine    │   │ Check    │
    └────┬─────┘    └────┬──────┘   └────┬─────┘
         │               │               │
         └───────────────┼───────────────┘
                         ▼
                ┌─────────────────┐
                │ Decision Engine │
                │ APPROVE/REVIEW/ │
                │ DECLINE         │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Payment Router  │ ← picks rail by amount/region
                └─────────────────┘

Let's walk through the parts that matter.

The State Machine

Anyone who has built a payments system the second time knows that the first thing you build the second time is a proper state machine. Withdrawals can't be modeled as Boolean flags on a row.

Our states:

type WithdrawalState =
  | 'PENDING'          // initial
  | 'RISK_SCORING'     // parallel checks running
  | 'AWAITING_REVIEW'  // flagged for human review
  | 'APPROVED'         // ready to dispatch to payment rail
  | 'DISPATCHED'       // sent to processor, awaiting confirmation
  | 'SETTLED'          // money has left our system
  | 'FAILED'           // processor rejected
  | 'DECLINED'         // we declined (fraud/compliance)
  | 'CANCELLED';       // player cancelled before dispatch

const validTransitions: Record<WithdrawalState, WithdrawalState[]> = {
  PENDING:         ['RISK_SCORING', 'CANCELLED'],
  RISK_SCORING:    ['APPROVED', 'AWAITING_REVIEW', 'DECLINED'],
  AWAITING_REVIEW: ['APPROVED', 'DECLINED'],
  APPROVED:        ['DISPATCHED', 'CANCELLED'],
  DISPATCHED:      ['SETTLED', 'FAILED'],
  SETTLED:         [],
  FAILED:          ['APPROVED'], // retryable on a different rail
  DECLINED:        [],
  CANCELLED:       [],
};

function transition(
  current: WithdrawalState,
  next: WithdrawalState
): void {
  if (!validTransitions[current].includes(next)) {
    throw new InvalidTransitionError(current, next);
  }
}

The transitions are persisted as an event log, not just current-state mutations on the row. This matters because:

You can replay a withdrawal's history for debugging.
Compliance audits become trivial.
Recovery from partial failures is bounded - you know exactly where you were.

A surprising number of iGaming platforms still model this as status: string on a withdrawals table and update it in place. That's how you end up with money "already sent," but the row still shows pending because two services raced.

Idempotency or Death

The single most important property of the entire pipeline is that every external call is idempotent.

When you're moving money, network failures are not edge cases. They are the case. Your payment processor will time out. Your fraud-scoring service will return 502. Your queue will redeliver. If any of these can cause double-spending, you don't have a payment system; you have a lawsuit waiting.

Every external operation gets an idempotency key derived deterministically from the withdrawal:

function idempotencyKey(
  withdrawalId: string,
  operation: string,
  attempt: number
): string {
  return `wd:${withdrawalId}:${operation}:${attempt}`;
}

// Usage with a payment processor
async function dispatchToProcessor(
  withdrawal: Withdrawal,
  attempt: number
) {
  const key = idempotencyKey(withdrawal.id, 'dispatch', attempt);

  return await processor.createPayout({
    amount: withdrawal.amount,
    currency: withdrawal.currency,
    destination: withdrawal.destination,
    idempotency_key: key, // processor dedupes server-side
  });
}

The attempt field is critical. If a payout legitimately fails on rail A and you retry on rail B, you want a new idempotency key - not a replay of the failed attempt. Most processors will return the cached failure if you reuse the key.

Parallel Risk Scoring

The legacy iGaming pattern is sequential: KYC check, then AML check, then fraud check, then liquidity check, each waiting on the last. Total time: minutes.

We run them in parallel and combine the scores:

async function scoreWithdrawal(
  withdrawal: Withdrawal
): Promise<RiskDecision> {
  const [risk, compliance, liquidity, velocity] = await Promise.all([
    riskEngine.score(withdrawal),       // ML model on player behavior
    complianceEngine.check(withdrawal), // sanctions, AML thresholds
    liquidityCheck(withdrawal),         // do we have funds on this rail?
    velocityCheck(withdrawal),          // recent withdrawal patterns
  ]);

  // Hard fails short-circuit immediately
  if (compliance.status === 'BLOCKED') {
    return { decision: 'DECLINED', reason: compliance.reason };
  }

  if (!liquidity.sufficient) {
    return { decision: 'DECLINED', reason: 'INSUFFICIENT_LIQUIDITY' };
  }

  // Combine soft signals
  const compositeScore =
    risk.score * 0.5 +
    velocity.score * 0.3 +
    compliance.softScore * 0.2;

  if (compositeScore < THRESHOLD_AUTO_APPROVE) {
    return { decision: 'APPROVED' };
  }

  if (compositeScore < THRESHOLD_REVIEW) {
    return { decision: 'AWAITING_REVIEW', score: compositeScore };
  }

  return { decision: 'DECLINED', reason: 'HIGH_RISK_SCORE' };
}

The thresholds are tunable per jurisdiction and per player tier - a verified player with a year of clean history gets different thresholds than a brand-new account. This is where you spend most of your time as the system matures.

Payment Rail Routing

The other thing legacy platforms do badly: they pick a single payment processor and route everything through it. When the processor degrades (and they all do, regularly), withdrawals back up.

Modern routing is multi-rail with active health checking:

interface Rail {
  id: string;
  supportsCurrency(c: Currency): boolean;
  supportsRegion(r: Region): boolean;
  feeFor(amount: Amount): Amount;
  estimatedSettlement(): Duration;
  healthScore(): number; // 0-1, updated by background prober
}

function selectRail(
  withdrawal: Withdrawal,
  rails: Rail[]
): Rail {
  const eligible = rails
    .filter(r => r.supportsCurrency(withdrawal.currency))
    .filter(r => r.supportsRegion(withdrawal.region))
    .filter(r => r.healthScore() > 0.7);

  if (eligible.length === 0) {
    throw new NoRailsAvailableError();
  }

  // Score by cost + speed + health
  return eligible.sort((a, b) => {
    const scoreA = railScore(a, withdrawal);
    const scoreB = railScore(b, withdrawal);
    return scoreB - scoreA;
  })[0];
}

The health score is updated by a background process that does small probe transactions and watches for elevated error rates. When a rail starts degrading, traffic shifts away from it automatically - players don't experience the outage, they just get routed to a healthier rail.

What Surprised Me

A few things I didn't expect when we started building this:

Most slow withdrawals are not fraud reviews. They're queuing. When you instrument the legacy flow, the actual time spent on risk and compliance checks is small - usually seconds. The hours and days come from work, sitting in queues waiting for human attention. The fix isn't "faster fraud detection," it's "stop putting things in human queues that don't need to be there."

Idempotency bugs are silent. A double-payout doesn't crash your system. It just quietly costs you money and shows up days later in reconciliation. Test your idempotency by deliberately replaying every external call in your dev environment. If your numbers don't match exactly, you have a bug in production right now.

Compliance is faster than you think when modeled correctly. Most operators treat compliance as a black box that returns "yes/no" after some time. In practice, compliance is a deterministic function of (player profile, transaction details, jurisdiction rules). It can run in milliseconds if you've structured the rules correctly. The slow part is when humans get involved - and humans should only be involved on the edges, not the median case.

Players notice the speed before they notice anything else. This is the part that surprised me as an engineer. We obsessed over the architecture, but the player feedback we got was almost entirely about how fast the payouts felt. Not the games. Not the UI. The thing they cared about most was the thing the industry has historically given them least of.

Why This Matters Beyond iGaming

The patterns above - state-machine modeling, idempotency-by-default, parallel scoring, multi-rail routing - generalize to basically any system that moves money. iGaming is just an industry where the gap between what the technology can do and what operators actually deliver is unusually wide, which makes it interesting to work in if you like building a better version.

If you're working on payments anywhere - fintech, e-commerce, marketplaces - and your withdrawal/payout flow looks like a synchronous queue with manual review, you have low-hanging fruit. The architectural change isn't large. The user-experience change is enormous.

Closing

The "slow withdrawal" problem in online gaming is fundamentally an architectural debt problem dressed up as a regulatory one. The platforms that figure this out are going to define the next decade of the category. The ones that don't will keep losing players to the ones that do.

If you're curious what this looks like as a finished product, 6ense is the platform we're building it on. Curaçao GCB licensed (OGL/2024/431/0231), built around the patterns above. Adults 18+ only, please play responsibly.

Happy to discuss any of the architecture in the comments. I'm particularly interested in how other payment-engineering teams handle the rail-health-scoring problem - there's a lot of room for better approaches there.

Edit: a few people asked about the fraud-scoring model - it's a separate post, will write one up if there's interest. The short version is gradient-boosted trees on behavioral features, retrained weekly, with hand-coded rules layered on top for known fraud patterns.