---
title: "How to evaluate a wallet integration provider: 12-point checklist"
seoTitle: "How to evaluate a wallet integration provider: 12 checks"
description: "A 12-point checklist for choosing a wallet or stablecoin payments provider: custody, chains, rails, pricing, compliance, SOC 2, SLAs, and AI tooling."
date: "2026-09-29"
updated: "2026-09-29"
category: "stablecoins"
author: "BlindPay Team"
faq:
  - q: "How do I choose a crypto wallet integration provider?"
    a: "Rank candidates on five criteria first: the custody model and who can sign without you, chain and stablecoin coverage, local payout rails if money must reach bank accounts, pricing transparency including pre-funding, and compliance coverage. Then check developer experience, security reports, SLAs, and support in a two-week proof of concept on the provider's sandbox, not in a sales demo."
  - q: "What is the most important criterion for a wallet provider?"
    a: "The custody model, because it decides who can move the funds, what happens if the provider fails, and which licenses your own company may need. Ask for a diagram of who holds keys or key shares for each product, and who can sign a transaction without you or your users. Every other criterion is easier to fix later than custody."
  - q: "What questions should I ask a wallet provider in a demo?"
    a: "Ask them to show, not tell: who can sign from your wallets without your approval, a failed payout from start to finish, what happens to your funds if they lose a banking partner, how a quote is priced and how long it holds, and how you would leave. Ask for the answers in writing, with the contract clauses that back them."
  - q: "What are red flags in a stablecoin infrastructure provider?"
    a: "Fees that only appear as one blended rate, mandatory pre-funding with no clear reason, custody claims without a key diagram, a sandbox that only returns success, no signed webhooks, FX rates set at settlement instead of quoted upfront, and licenses you can't find on a regulator's public register. Any one of these deserves a direct question before you sign."
  - q: "How long should a wallet provider proof of concept take?"
    a: "Two weeks is enough for most teams. In ten working days you can onboard test customers, link or create wallets on your main chain, run a pay-in and a payout end to end, verify webhooks, force failures and refunds, and add a second chain or rail. Write the success criteria on day one, so the decision on day ten is a scorecard, not a debate."
  - q: "Is BlindPay a wallet provider?"
    a: "No. BlindPay is the payments layer that connects wallets to bank accounts: virtual accounts, on-ramps and off-ramps, live quotes, and local payouts. It links external wallets without holding their keys and offers managed wallets in beta. For key management across thousands of end-user wallets, pair a wallet infrastructure provider with BlindPay for the bank side."
---

To choose a wallet integration provider, rank candidates on five things first: the custody model and who can sign without you, chain and stablecoin coverage, local payout rails if money has to reach bank accounts, pricing transparency including pre-funding, and compliance coverage. Then test developer experience in a two-week proof of concept, not a sales demo.

This checklist covers both halves of a wallet stack: the wallet infrastructure that holds and signs, and the payments layer that connects wallets to bank accounts. Many teams evaluate the two separately and discover the gap between them in production. For the payments API alone, [how to choose a blockchain payment API](/resources/more/how-to-choose-a-blockchain-payment-api) goes deeper on SDKs, OpenAPI quality, and abstraction level.

## How do you choose a wallet integration provider?

Start with the five criteria that are hardest to change after launch, and score the rest in a proof of concept. Custody, coverage, rails, pricing, and compliance shape your architecture and your licensing. Developer experience and support shape your roadmap.

The top five, in order:

1. **Custody model.** Who holds keys or key shares, and who can sign without you or your users. [Custodial vs non-custodial vs MPC wallets](/resources/more/custodial-vs-non-custodial-vs-mpc-wallets) explains the options.
2. **Chain and stablecoin coverage.** Which networks and tokens are live in production today, not on the roadmap.
3. **Local payout rails.** If money has to reach bank accounts, which rails are live in which countries.
4. **Pricing transparency and pre-funding.** Whether fees are itemized before execution, and whether you have to park a balance with the provider.
5. **Compliance coverage.** Which checks run inside the product, and which licensed entity serves each market.

## The 12-point evaluation checklist

Send the same twelve questions to every vendor on your shortlist and score the written answers. A good answer is specific and checkable. A weak answer is a promise.

| # | Criterion | What to ask | What a good answer looks like |
| --- | --- | --- | --- |
| 1 | Custody model | Who holds the keys or shares, and who can sign without us? | A diagram per product, with custodial and non-custodial products named separately |
| 2 | Chain coverage | Which chains are live in production, and which signature schemes do you support? | A published matrix of mainnets and matching testnets |
| 3 | Stablecoin coverage | Which tokens are supported on which chains? | A per-chain token list, with unsupported pairs rejected by a clear error |
| 4 | Local payout rails | Which rails are live, in which countries, in production? | Named rails such as Pix, SPEI, ACH, and SEPA, each marked live |
| 5 | Developer experience | Is there a REST API, a downloadable OpenAPI spec, SDKs, and a sandbox? | An [OpenAPI 3.1](https://spec.openapis.org/oas/v3.1.0) spec, SDKs in several languages, and a sandbox with the same states as production |
| 6 | Pricing and pre-funding | How are fees charged, and must we pre-fund a balance? | Fees itemized in every quote; no pre-funding, or a clear reason for it |
| 7 | FX and live quotes | How is the rate set, and how long does a quote hold? | A firm quote with an expiry and a visible fee split before execution |
| 8 | Compliance coverage | Which checks run in the product: KYC, KYB, sanctions, address screening, KYT, Travel Rule? | Named checks with statuses in the API, plus the licensed entity per market |
| 9 | Security certifications and audits | Which SOC 2 report, which penetration tests, which contract audits? | A [SOC 2](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) Type 2 report under NDA and a recent pentest summary |
| 10 | Uptime and SLA | What exactly does the SLA measure? | A split between API uptime and settlement timing, and a status history |
| 11 | Support and migration path | Who answers during an incident, and how do we leave? | A named escalation path, plus key, address, and data export terms in the contract |
| 12 | AI-agent and MCP tooling | Can coding agents build against the API? | An [MCP](https://modelcontextprotocol.io/) server, agent skills, and docs that load cleanly into an agent |

Two items deserve extra time. On item 9, a SOC 2 Type 2 report covers how controls operated over a period, while a Type 1 covers a single date. On item 10, [stablecoin API SLAs](/resources/more/stablecoin-api-sla-settlement-finality) explains why an API can report high uptime while money is still in flight.

## What questions should you ask in a vendor demo?

Ask the vendor to show each answer live in the sandbox, and to follow up in writing. Demos are built around the happy path, so these ten questions go straight to the other paths:

1. Show me every way a transaction can leave our wallets without our approval.
2. Walk a failed payout from start to finish: which status, which webhook, and where do the funds end up?
3. What happens to our funds if you lose a banking partner tomorrow?
4. Which licensed entity serves each of our corridors, and where can we check it?
5. Show a quote: the rate, every fee, the expiry, and what happens when it expires.
6. Do we need to pre-fund a balance, and if so, who holds it and in whose name?
7. How do we prove a customer controls a wallet address before it receives funds?
8. What does address screening return, and what happens when an address is flagged?
9. How do we export our keys, addresses, and transaction history if we leave?
10. Who do we call during an incident, and how fast do they answer?

## What red flags should you watch for?

Red flags are answers that hide cost, custody, or failure behavior. None of them is disqualifying on its own, but each deserves a direct question before you sign:

- **Hidden fees.** One blended rate, with no split between FX spread and transaction fee. [Stablecoin API pricing](/resources/more/stablecoin-api-pricing-explained) shows how to read a quote line by line.
- **Mandatory pre-funding.** A balance you must park with the provider before paying out, with no clear reason. [What no pre-funding means](/resources/more/no-pre-funding-stablecoin-payouts) covers the alternatives.
- **Unclear custody.** "Non-custodial" in the pitch, with no key or share diagram behind it.
- **No real sandbox.** A test environment that only returns success, so failure paths first show up in production.
- **No webhooks, or unsigned ones.** Polling-only status, or payloads you can't verify.
- **Opaque FX.** A rate set at settlement instead of quoted upfront. [Stablecoin FX slippage](/resources/more/stablecoin-fx-slippage-live-quotes) explains the difference.
- **Unverifiable licenses.** Registrations you can't find on a regulator's public register, such as FinCEN's [MSB registrant search](https://www.fincen.gov/msb-registrant-search).

## How do different provider types compare?

Wallet integration touches four kinds of providers, and each is best at a different job. Most production stacks combine two of them, usually a wallet provider and a payments layer. [Wallet API vs embedded SDK vs white-label](/resources/more/wallet-api-vs-embedded-wallet-sdk-vs-white-label) covers how the wallet side plugs in.

| Provider type | Examples | Best at | Usually paired with |
| --- | --- | --- | --- |
| Payout and on/off-ramp infrastructure | BlindPay | Converting between bank money and stablecoins: virtual accounts, live quotes, local payouts | A wallet provider, or the customer's own wallet |
| Wallet infrastructure providers | Fireblocks, Circle wallets, Privy, Dfns, Utila | Key management, signing policies, embedded and treasury wallets | A payments layer for bank rails |
| Stablecoin issuers | Circle (USDC), Tether (USDT) | Issuing and redeeming the stablecoin itself | Ramps and payout providers for last-mile delivery |
| Exchanges and ramps | Centralized exchanges, consumer ramp apps | Trading liquidity and retail buying and selling | Wallets for storage and transfers |

The categories overlap at the edges. Some wallet providers add fiat connectivity through partners, and some issuers run payout networks. Ask each vendor which job it does itself and which it hands to a partner.

## How do you run a 2-week proof of concept?

A proof of concept should run your real flows in the provider's sandbox for ten working days, against success criteria written on day one. The goal is a scorecard, not a feeling.

1. **Day 1:** get sandbox access and API keys, and write the success criteria with engineering, product, and compliance.
2. **Day 2:** create test customers and run KYC and KYB, including one rejection.
3. **Day 3:** create or link wallets on your main chain, and prove wallet ownership at registration.
4. **Day 4:** run a pay-in end to end, from bank deposit to stablecoins in the wallet.
5. **Day 5:** run a payout end to end: quote, wallet authorization, execution, and fiat delivery. [How to add stablecoin payments to your wallet integration](/resources/more/how-to-add-stablecoin-payments-to-your-wallet-integration) has the steps.
6. **Day 6:** verify webhook signatures, replay duplicate events, and reconcile against your ledger.
7. **Day 7:** force failures: an expired quote, a failed payout, a refunded payout.
8. **Day 8:** add a second chain or a second payout rail.
9. **Day 9:** compliance and security review: the data collected, the checks visible in the API, the SOC 2 report.
10. **Day 10:** price the setup against your projected volume, score the checklist, and decide.

Success criteria worth writing down: every payment state reached in the sandbox, every failure path landing in the right order state, webhook signatures verified, pricing reproduced from quotes, and written answers to all twelve checklist items.

## When is BlindPay a good fit, and when is it not?

BlindPay fits teams that need wallets connected to bank accounts across borders, with the customer's funds staying in the customer's wallet until a payout executes. It doesn't fit teams that need key management, card acquiring, or a stablecoin of their own.

BlindPay is a good fit when you need:

- **Non-custodial cross-border stablecoin flows.** Payouts from external wallets pull only the quoted amount at execution, and BlindPay never holds those wallets' keys. Managed wallets, in beta, cover teams that prefer custody.
- **Virtual accounts.** US bank details per customer, with each deposit converted to USDC or USDT and settled to the linked wallet.
- **Local-currency payouts.** Pix, SPEI, ACH, RTP, SEPA, SWIFT (POBO/COBO), TED, ACH Colombia, and Transfers 3.0. Cross-border wires run as SWIFT payments and collections on behalf of the customer, with UETR tracking and MT103 confirmations.
- **No pre-funding and no volume floor.** Plans are on the [pricing page](/pricing), with no setup fee and no monthly minimum, and every quote itemizes its fees before execution.
- **Chain coverage.** Ethereum, Polygon, Base, Arbitrum, Tempo, Arc, Stellar, Solana, and Tron, per the [supported chains](/docs/kb/supported-chains) matrix.
- **Developer and agent tooling.** An OpenAPI 3.1 spec, [SDKs](/docs/sdks) for Node.js, Python, Go, PHP, and Swift, an MCP server, agent skills, and a [prompt library](/prompts) for coding agents.

BlindPay is registered with FinCEN as a money services business ([licenses](/licenses)), and its [security page](/security) lists SOC 2 Type 2.

BlindPay is not the right fit when you need a stablecoin issuer, card acquiring, a consumer wallet app, or key-management infrastructure for end-user wallets. For those, pick a specialist, and use the table above to see where BlindPay can sit behind it.

## What to do next

Copy the 12-point table into a spreadsheet, send it to every vendor on your shortlist, including us, and book the two-week proof of concept with the two strongest written answers. Decide on the scorecard, not the demo.

If you're still defining scope, start with [what is crypto wallet integration](/resources/more/what-is-crypto-wallet-integration), then check your launch plan against the [crypto wallet compliance checklist](/resources/more/crypto-wallet-compliance-checklist) before the first vendor call.