RedotPay

  • Name: RedotPay
  • URL: https://www.redotpay.com/
  • Category: stablecoin spend-and-settlement operator / card-and-wallet company / merchant-payments and payout middleware company
  • Tags: ethereum-ecosystem bitcoin-ecosystem
  • Summary: RedotPay belongs in companies/ because the durable dependency is not just a card app or merchant checkout flow. It is a named operator that decides merchant admission, API-key and key-exchange workflow, callback-signature trust, settlement timing, supported assets and networks, user KYC and card eligibility, and how consumer wallet balances, card issuance, merchant checkout, and international-transfer payout routes are packaged together. The useful question is not just can people spend stablecoins here? but which company controls the settlement, compliance, and account workflow shell behind that spending?
  • What it does:
    • Operates a stablecoin-based consumer payments app with wallet balances, virtual and physical cards, and global merchant spending
    • Runs RedotPay Connect so merchants can accept stablecoin payments while receiving fiat settlement, with both hosted Paylink checkout and OpenAPI-based custom integration modes
    • Requires production-style merchant security workflow including RSA request signing, callback verification with RedotPay public keys, and recommended annual key rotation
    • Supports consumer funding through on-chain deposits, Binance Pay, and in some cases card-based crypto purchases, while also handling app-based identity verification before card issuance
    • Offers international transfer workflows that convert crypto such as USDT, USDC, or BTC into local-currency payouts to bank accounts or e-wallets
    • Packages consumer wallet, card, merchant settlement, and payout rails under one company shell rather than exposing a neutral underlying payment standard
  • Key claims:
    • The RedotPay Connect docs say websites and apps can accept stablecoin payments while merchants receive direct payouts in local currency, with standard T+1 settlement in USD as the clearest documented baseline
    • The payment guide says merchants can integrate either through hosted Paylinks or through OpenAPI flows that return URLs, QR codes, deeplinks, and other custom checkout primitives, which is strong evidence of a real merchant control plane rather than a simple hosted page
    • The signature and verification guide says production and gray-environment requests with body parameters must be signed with SHA256withRSA, that merchants upload public keys to RedotPay, verify callbacks using RedotPay’s public key, and rotate keys regularly
    • The Open API v2 migration guide shows RedotPay standardizing order creation, payment-method retrieval, query, and refund behavior behind one backend order model, including QR-code and deep-link responses for custom payment pages
    • The help center says RedotPay is a stablecoin-based payment app with virtual and physical cards, wallet balances, ATM withdrawals, and availability across 158+ countries, which reinforces that the company controls a broader spend stack than the merchant docs alone reveal
    • The card-onboarding flow requires in-app identity verification and account funding before virtual or physical card issuance, which makes the consumer compliance and eligibility shell part of the real control surface
    • The international-transfer help article shows RedotPay also packages crypto-to-local-currency payout routes into banks and e-wallets, including corridors tied to recognizable local networks such as Pix, SPEI, and SEPA
  • Whitepaper: No classic standalone company whitepaper is the important artifact here. The clearest primary materials are the RedotPay Connect docs plus the consumer help-center articles for services, card onboarding, and international transfers; the broader source bundle remains ../whitepapers/redotpay-primary-sources-2026-05-07.md.
  • Sources:

Internal linkages

Protocol / company boundary

  • redotpay should stay focused on the merchant integration surface and user-facing spend product: hosted-versus-custom checkout shape, card and wallet UX, callback model, and payout timing exposed to integrators.
  • This company note isolates the broader operator shell: merchant onboarding, API-key and key-exchange workflow, callback-signature trust, asset-and-network policy, settlement timing, consumer KYC and card eligibility, and the packaging of wallet, card, merchant, and transfer rails all sit with RedotPay as a named company.
  • That split matters because the dependency merchants and users inherit is not a neutral stablecoin spend primitive. It is a company-managed workflow graph spanning consumer accounts, merchant settlement, and payout operations.

Control surface

  • Practical leverage sits in merchant admission, supported asset and network policy, signature and key-rotation rules, callback verification, settlement timing, consumer identity checks, card-issuance eligibility, transfer-corridor exposure, and the dashboard or support surfaces users and merchants trust when balances or payouts are disputed.

  • The sticky dependency is operational memory: once merchants and users harden around RedotPay-managed keys, callbacks, card issuance, transfer corridors, and settlement assumptions, the real lock-in is to the company-run spend-and-settlement shell rather than only to a checkout API or card brand.

  • Read RedotPay as a company-operated account, settlement, and payout boundary first, and as a card or merchant product second.

  • Last reviewed: 2026-08-07 UTC