RedotPay

• Name: RedotPay
• URL: https://www.redotpay.com/
• Category: stablecoin spend-and-settlement middleware / card-and-wallet operator stack / crypto-to-fiat settlement layer
• Tags: ethereum-ecosystem bitcoin-ecosystem
• Summary: RedotPay at the project layer is the merchant checkout and user-facing spend surface inside a broader RedotPay company shell. The card app is the shell. The useful product cut is the integration and spend surface itself: merchant flows, signed-request policy, callback truth, compliance gating, payout timing, and fiat settlement behind the stablecoin flow.
• What it does:
  • Runs a stablecoin-based payments app with wallet balances, virtual and physical cards, and global merchant spending
  • Lets users fund accounts through on-chain deposits, Binance Pay, and in some cases card-based crypto purchases, then spend through RedotPay cards or supported payment flows
  • Supports international transfer workflows that convert crypto such as USDT, USDC, or BTC into local currency sent to bank accounts or e-wallets
  • Operates RedotPay Connect, a merchant-facing payment stack that lets websites or apps accept stablecoin payments while merchants receive fiat settlement
  • Offers both redirect-style hosted checkout through Paylinks and more customized Open-API flows with QR codes, deeplinks, and merchant-managed payment displays
  • Exposes operational integration details around signed API requests, callback verification, key versioning, and v2 migration for merchant payment flows
• Key claims:
  • The merchant docs say RedotPay Connect lets websites and apps take stablecoin payments while merchants receive fiat settlement, with standard T+1 USD settlement the clearest currently documented baseline
  • The merchant stack is simple but real: hosted Paylinks for redirect checkout, OpenAPI flows for custom payment pages, and explicit QR-code, deeplink, query, and refund handling in the v2 API shape
  • The hard operator edge is policy, not UX: signed requests, callback verification, key exchange, recommended annual key rotation, merchant KYB, and ongoing compliance review decide who can actually use the stack safely
  • The consumer app matters mainly because it concentrates spending policy in one shell — card issuance, crypto funding, wallet balances, and ATM withdrawal — not because it turns RedotPay into an account substrate
  • The international-transfer product broadens the operator surface a bit by adding crypto-to-local-currency payout routing into bank accounts and e-wallets, but it is still the same hosted settlement business, not a new rail
• Whitepaper: No canonical standalone RedotPay whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the RedotPay Connect docs and the consumer help-center articles for wallet/card operations and international transfers; see ../whitepapers/redotpay-primary-sources-2026-05-07.md.
• Sources:
  • https://www.redotpay.com/
  • https://redotpay.readme.io/
  • https://redotpay.readme.io/reference/payment
  • https://redotpay.readme.io/docs/redotpay-api-request-signature-and-verification-guide
  • https://redotpay.readme.io/docs/open-api-v2-upgrade-guide
  • https://helpcenter.redotpay.com/en/articles/11070044-redotpay-services-and-features
  • https://helpcenter.redotpay.com/en/articles/11008771-how-to-get-a-redotpay-card
  • https://helpcenter.redotpay.com/en/articles/11325255-how-redotpay-international-transfer-works

Internal linkages

• Company boundary for the broader operator shell: redotpay.
• Keep the note pointed at the strongest card-and-wallet product/control-plane anchors: gnosis-pay and rain.

Protocol / company boundary

• Keep this note on the product-layer spend and checkout surface: merchant integration shape, Paylink versus OpenAPI flow selection, signed-request and callback behavior, payout timing, and the card-and-wallet UX users or merchants directly encounter.
• Use redotpay for the named-operator layer around merchant onboarding, key exchange, supported asset-and-network policy, settlement timing, consumer KYC and card eligibility, transfer-corridor exposure, and the company-run support and dispute shell.
• That split matters because how does the RedotPay spend and merchant product behave? and which company controls who gets access, what corridors stay live, and how settlement or support policy works? are related but not identical questions.

Control surface

• At the product layer, authority sits in checkout mode selection, signed-request policy, callback verification, payout timing, card-and-wallet UX, and which payment methods RedotPay actually surfaces to users and merchants.

• The broader operator dependency sits one layer up in redotpay: merchant onboarding, key exchange, supported asset-and-network policy, settlement timing, consumer KYC and card eligibility, and the company-run support truth when balances or payouts are disputed.

• The consumer wallet and card shell matters because it concentrates spending and account policy, but the merchant side is still hosted settlement plumbing with fiat-settlement defaults.

• Treat it as stablecoin spend-and-settlement middleware, not as a payment standard or account substrate.

• Last reviewed: 2026-08-13 UTC