Why Did Kraken Buy Reap Instead of a U Card?

The U Card is merely the front end seen by users; what truly holds value is the infrastructure behind it, including the issuance system, card organization network, compliance, and settlement systems for stablecoins.

Written by: Yuki

Kraken's parent company, Payward, plans to acquire Reap for up to $600 million, which serves as a great entry point for understanding stablecoin payments. According to the official announcement from Payward and Reap, Reap is defined as a stablecoin-native, card issuing and payments infrastructure company. After the transaction is completed, Reap's capabilities will be integrated into Payward Services to support card issuance, cross-border payments, and stablecoin treasury services.

These terms are crucial. They indicate that what Payward is purchasing is not just a product that can issue U Cards, but a comprehensive infrastructure related to card issuance, cross-border payments, stablecoin settlements, and corporate fund management. Therefore, I believe the most pertinent question is not, "Why does Kraken want to issue U Cards?" but rather: If it merely wanted to issue a U Card, why not directly acquire a front-end U Card brand?

There are already many U Card products in the market that users perceive more strongly. Users can open an app, recharge with USDT or USDC, link a virtual or physical card, and then spend online or offline. This narrative is easy to understand: stablecoins can finally be spent like a bank card balance. However, what Payward is acquiring is not a simple U Card brand aimed at end-users. It is acquiring Reap.

This indicates that what it truly wants to supplement is not the front-end capability of "issuing a card to users," but rather the more complex, heavier, and more valuable infrastructure behind it: card issuance, authorization, stablecoin settlement, cross-border payments, corporate treasury, compliance risk control, and the ability to connect with traditional financial rails. In other words, the U Card is merely the visible result for users.

What is truly valuable is the ability to issue this card, have it accepted by merchants through the Visa/Mastercard network, and complete the conversion, settlement, reconciliation, risk control, and compliance of stablecoins to fiat currency in the backend.

Thus, the real aim of this article is not to determine which U Card is the best to use, but to explore another matter: what kind of infrastructure companies like Reap, Rain, and StraitX are actually building? Why are they being targeted by exchanges, wallets, fintech companies, and even traditional payment giants?

Because the ability to issue a U Card is far more complex than simply "creating an app + connecting a card number." It requires simultaneously integrating the card organization network, card issuance qualifications, BIN sponsorship, issuer processing, real-time authorization, stablecoin deposits and conversions, on-chain and off-chain accounting, corporate fund management, cross-border settlements, KYC/KYB, AML, chargeback management, fraud risk control, and local banking and payment rails. This is why there can be many front-end U Card brands, but very few companies can actually build the necessary infrastructure.

Front-end products address the question of "what do users see?" Infrastructure companies tackle the question of "why can this card actually be issued, used, settled, and who can back it up when problems arise?"

The significance of Payward's acquisition of Reap should be understood in this context. It is not simply acquiring a U Card entry point but is instead supplementing a complete set of stablecoin payment infrastructure capabilities. Next, let’s break down the most fundamental question regarding a U Card: how is it actually issued?

How is a U Card Actually Issued?

Many people might think that a U Card is issued by a specific exchange, wallet, or crypto app. However, the front-end brand that users see is often just the top layer of the industry chain.

A truly usable U Card requires at least several layers of capabilities to be pieced together: card organization network, card issuance qualifications, BIN sponsorship, issuer processing, program management, stablecoin infrastructure, and finally the front-end product aimed at users. This is why I previously stated that a U Card is not a single-point product but rather a complete industry chain.

The first layer is the card network, such as Visa and Mastercard.

They provide a global merchant acceptance network, transaction rules, clearing rules, dispute resolution frameworks, and network branding. When users swipe their cards offline or enter their card numbers online, merchants typically do not know that this is a "U Card." What they see is a card that can be processed through the Visa or Mastercard network. Therefore, U Cards do not bypass Visa/Mastercard; on the contrary, many U Card products leverage the merchant networks of Visa/Mastercard to allow stablecoin balances to enter real-world consumption scenarios.

The second layer is the issuer / issuing bank / issuing institution, which refers to the entities that are truly qualified to issue cards.

This should not be simply understood as "it must be a bank." In traditional card businesses, issuers are often banks. However, in the realm of crypto cards or fintech cards, the actual issuers may also be electronic money institutions, payment institutions, or licensed fintechs with principal membership in Visa/Mastercard. Their commonality is that they are qualified to participate in card issuance and bear responsibilities related to transactions, funds, compliance, chargebacks, and fraud.

For example, some crypto cards are backed by banks, while others are backed by electronic money institutions or licensed payment institutions. The Coinbase Card is issued in the U.S. by Pathward, N.A.; the Nexo Card is launched in Europe in collaboration with Mastercard and DiPocket; the Crypto.com Visa Card is issued and distributed in Singapore by Foris Asia Pte. Ltd., which holds a MAS Major Payment Institution License. The issuer structure may vary significantly across different regions and products. Thus, while many front-end brands may appear to issue cards themselves, there is always an issuer, issuing institution, or licensed partner bearing the responsibility of card issuance. This is why "issuing a card" is not something that can be done simply by an app's desire.

The third layer is the BIN sponsor.

BIN refers to the Bank Identification Number, which corresponds to the first few digits of the card number. It determines which issuing institution the card belongs to, what type of card it is, which network it operates on, and which region it serves. Many fintech or crypto platforms lack complete card issuance qualifications and thus need to connect to card issuance capabilities through a BIN sponsor. BIN sponsors provide qualifications and channels, but they do not do so unconditionally. They require projects to comply with regulations, risk controls, funding, and operational rules.

For crypto cards, this layer is particularly critical. If high-risk transactions, fraud, chargebacks, or regulatory issues arise, the responsibility does not rest solely with the front-end brand. BIN sponsors, issuers, processors, and project management parties may all be implicated.

The fourth layer is the issuer processor.

This layer is responsible for handling authorizations, settlements, transaction routing, balance verification, card controls, limits, risk control rules, and transaction event callbacks. When a user swipes their card, the merchant initiates an authorization request. The processor must quickly determine: Is this card valid? Is the balance sufficient? Is this transaction allowed? Are there any issues with the merchant category? Are there any regional restrictions? Is the risk acceptable? Then it must return the result to the card network and the merchant. If the card is linked to a stablecoin balance, the situation becomes more complex. The system must not only check a fiat account balance but also handle stablecoin balances, exchange rates, freezes, conversions, on-chain and off-chain accounting, and subsequent reconciliations.

The fifth layer is the program manager.

This functions as the operational brain of a card project. Who is the card open to? Is it a C-end consumer card or a corporate card? Is it a virtual card or a physical card? Which regions are supported? What merchant categories cannot be used? What KYC do users need to complete? What KYB do corporate clients need to fulfill? How are fees charged? What are the transaction limits? How are chargebacks handled? How does customer service respond? All of these fall under the purview of program management. Some companies act as their own program managers, while others delegate this capability to infrastructure service providers.

The sixth layer is the crypto or stablecoin infrastructure provider.

This layer is responsible for the stablecoin-related aspects: deposits, on-chain receipts, wallet accounting, stablecoin and fiat conversions, treasury management, on-chain and off-chain reconciliations, cross-border settlements, transaction monitoring, and compliance reviews.

However, it is important to note that companies like Reap, Rain, and StraitsX often do not merely stand at the sixth layer. Their value lies not in performing a single function but in packaging multiple layers of capabilities: card issuing, BIN sponsorship, program management, real-time authorization, stablecoin settlement, treasury, cross-border payments, and local financial connections.

Thus, they do not simply help clients "issue a card." They are solving a more complex problem: how to integrate the stablecoin balances held by users or enterprises into the traditional card issuance system, card organization network, compliance systems, and local financial systems. This is why these companies are referred to as infrastructure companies.

If the focus were solely on creating a front-end U Card product, the emphasis would be on user experience, customer acquisition, and scenario packaging. However, if the goal is to build infrastructure, the focus shifts to whether it can help different wallets, exchanges, fintech companies, or corporate clients connect the originally fragmented processes of card issuance, authorization, stablecoin settlement, cross-border fund flows, and compliance risk control.

The final layer is the frontend brand, which consists of the exchanges, wallets, crypto apps, or fintech products that users actually see.

The front-end brand is responsible for customer acquisition, product experience, card design, user operations, and scenario packaging. Users may think they are using a card from a specific wallet or exchange, but behind the scenes, it often involves a combination of card organizations, issuers, BIN sponsors, processors, program managers, stablecoin settlement parties, and compliance service providers.

Thus, a U card is not simply "a card issued by one company." To be precise, it is the result of collaboration among multiple institutions. What users see is a card, but behind it is a complete system that collectively handles card issuance, authorization, redemption, clearing, settlement, compliance, chargebacks, and risk management.

This is also why building stablecoin payment infrastructure is challenging. It is not merely a crypto technology issue or a card issuance issue; it is a system engineering challenge that spans Web3, traditional payments, banking, compliance, risk control, and local financial networks.

Companies that can achieve this level of integration often do so not because they "can issue cards," but because they have spent a long time establishing banking relationships, card organization relationships, licensing structures, risk control models, processor integrations, stablecoin accounting systems, and local settlement networks.

None of these elements can be quickly filled in with a round of funding or a single API document. This is also why Payward chose to acquire Reap, rather than just buying a front-end U card brand. A front-end brand can look attractive and grow quickly, but what is truly difficult to replicate is the underlying infrastructure that enables card issuance, processing, settlement, and ensures that someone can cover the issues when they arise.

How Does Money Move When a U Card is Swiped?

Previously, we discussed the roles needed to issue a U card. However, to truly understand the U card business, we must also consider another question: How does money move at the moment a user swipes their card?

Suppose a user has 100 USDC in their wallet, and they use this U card to make a purchase of $20 at an overseas merchant. From the user's perspective, this is straightforward: open the app, see the card, swipe it, and the balance decreases. However, what happens in the background is not that "the merchant directly receives 20 USDC." This is where many people misunderstand U cards.

In most cases, the merchant still follows the traditional card payment process. The merchant initiates a card transaction through an acquiring institution, which enters the Visa or Mastercard network and is routed to the corresponding issuer/processor system. In other words, what the merchant wants is not an on-chain transfer. What they want is a standard card transaction result: Can this card be charged? Can this transaction be authorized?

Then, the issuer processor receives the authorization request and begins a series of checks. Is this card valid? Is it frozen? Does the transaction amount exceed the limit? Is the merchant category allowed? Is the transaction area open? Is there a risk of fraud? Does the user account have sufficient balance? If the card is linked to a stablecoin balance, the system must also perform an additional check: Does the user's USDT or USDC balance cover this purchase, and is it sufficient after conversion to the merchant's settlement currency?

Next, there are two common processing methods.

One is real-time conversion. When the user swipes the card, the system immediately converts the corresponding value of stablecoins into fiat currency, completing authorization and subsequent settlement.

The other is to first freeze the ledger. The system first freezes the corresponding value of stablecoins in the user's account, and once the transaction enters the clearing and settlement phase, it performs conversion, reconciliation, and fund allocation.

The specific method used depends on the card project design, issuing region, requirements of partner banks, processor capabilities, types of stablecoin assets, liquidity arrangements, and the accounting systems of infrastructure service providers.

Regardless of the method, merchants typically do not directly collect USDC from the user's wallet. For merchants, what they receive is still a standard card transaction. They deal with acquiring institutions, card organizations, and issuing systems, not a blockchain. The real change occurs in the background funding sources and settlement logic. Users swipe on the Visa or Mastercard network, but the funds supporting this purchase may come from the stablecoin balance in the user's account. In the background, authorization, freezing, conversion, clearing, settlement, reconciliation, and fund allocation are completed among the platform, issuer, processor, card organization, acquirer, stablecoin infrastructure service provider, and local banks. This is the crux of the U card: the front end is the card network, and the back end is the stablecoin funding flow. Understanding this prevents the misconception that U cards are "replacing Visa/Mastercard with stablecoins."

At this stage, a more accurate statement is that stablecoins do not directly replace the merchant-side card acceptance network but become the funding source, treasury tool, and settlement asset behind card projects. This is why the real improvement brought by stablecoin cards may not necessarily be the merchant's front-end experience. Merchants can already accept Visa and Mastercard. What is truly changed is the way funds circulate behind the platform and issuing projects.

Traditional cross-border card projects often face several issues: funds must be pre-placed in different regions or partner banks, clearing slows down on weekends and holidays, cross-border transfers take time, multiple accounts need to maintain buffers, and funds can get stuck in different channels.

These issues may not be visible to users, but they directly affect the capital efficiency, authorization success rate, regional expansion speed, and profit margins of card projects. The value of stablecoins begins to emerge here. They can be transferred 24/7, continue to facilitate fund allocation on weekends and holidays, flow across wallets, platforms, and regions, and make some fund arrangements that originally took days to complete much closer to real-time. Therefore, U cards do not simply move "on-chain payments" to offline merchants. They are more like adding a new source of funds and settlement tools behind the traditional card network. Users see "I use stablecoins to swipe my card for consumption." Merchants see "I received a standard card transaction."

Infrastructure companies see "I need to connect authorization, conversion, clearing, settlement, reconciliation, and compliance risk control between these two systems." This is why this task is challenging. The difficulty does not lie in creating a card face or displaying a balance in the user app. The challenge is whether this system can determine in seconds whether a transaction can go through when a user actually swipes their card; after the transaction, can it reconcile stablecoins, fiat currency, card network clearing, local bank funds, corporate accounts, and compliance records?

If any link in this chain fails, what the user sees is a transaction failure, a frozen card, an abnormal balance, opaque exchange rates, or withdrawal restrictions.

Thus, whether a U card can truly scale is not determined by how many currencies are supported or how many regions are covered on the promotional page, but rather whether the backend system can stably handle these unglamorous but critical issues: Can authorization go through? Can funds arrive? Can accounts be reconciled? Can risks be controlled? Can compliance be explained? Is there someone to cover the issues when they arise? This is the real threshold for stablecoin payment infrastructure.

Why Are Overseas Players Incorporating Stablecoins into Card Business Backends?

As mentioned earlier, when users swipe U cards, what merchants see is still a standard card transaction. Merchants do not need to understand USDC or USDT, nor do they need to connect to on-chain wallets. Therefore, stablecoin cards do not directly replace Visa/Mastercard on the merchant side.

More accurately, in some overseas compliance scenarios, stablecoins are integrated into the backend of card projects as part of account balances, exchange arrangements, fund allocation, or settlement tools. This is where the complexity of this infrastructure truly lies.

It is not just about displaying a stablecoin balance in the user app or generating a virtual card number. The backend must also handle a complete set of issues: how to verify user balances, how to authorize during card swipes, how to convert between stablecoins and fiat currencies, how to reconcile transaction records and on-chain/off-chain accounts, how to allocate funds across different regions, and how to complete KYC/KYB, AML, sanctions screening, and transaction monitoring.

In other words, stablecoins here do not play the role of "replacing card networks" but are embedded in the backend of card business, participating in funding sources, accounting, conversion, settlement, and treasury management. However, this cannot be simply understood as "stablecoins making payments faster and cheaper."

In real business, they still face regulatory approvals, banking partnerships, on/off-ramp issues, card organization rules, liquidity, exchange rates, accounting treatments, taxes, and compliance reviews. The boundaries of different regions are also completely different.

Thus, some overseas payment companies, exchanges, and fintechs are exploring the use of stablecoins as part of backend funding and settlement tools, but whether they can scale depends on licenses, banking partnerships, risk control capabilities, local regulations, and compliance boundaries. This is why companies like Reap, Rain, and StraitsX are worth paying attention to.

What they are truly doing is not "issuing a cooler card," but connecting digital asset balances, issuing systems, card organization networks, corporate fund management, and local financial systems under overseas compliance frameworks. From this perspective, the core of stablecoin cards is not the front-end consumption experience but the backend infrastructure capability.

Who is Building the Infrastructure Behind U Cards?

Previously, we dissected the processes involved in issuing and swiping a U card from an "operational link" perspective. However, if we switch to a "company ecosystem" perspective, we will see another picture: this industry is not just about front-end U card brands but can be divided into several categories of players. At the top are the U card products visible to users. In the middle are the stablecoin card issuance, payment, and settlement infrastructure. At the bottom are traditional payment rails, processors, and compliance.

These two classifications are not in conflict. The seven layers explain: how a card operates. The four layers explain: who is building this system.

The first layer is the front-end U card/crypto card products. This layer is closest to the user and the easiest to see.

For example, RedotPay, Coinbase Card, Crypto.com Card, Bybit Card, Wirex, Nexo Card, MetaMask Card, Ledger CL Card, 1inch Card, Gnosis Pay, KAST, Bitget Wallet Card, etc.

They solve user experience issues: where users can open cards, how to recharge, how to consume, which currencies are supported, whether they can swipe online and offline, whether the rates are clear, whether the card will be frozen, and whether customer service can respond.

This is also the U card business that many people find easiest to understand. Because it seems very intuitive: users have USDT or USDC, and the platform gives them a card, allowing them to consume. However, this layer may not necessarily master the underlying capabilities of card issuance, authorization, clearing, settlement, and compliance. Many front-end brands still rely on issuing institutions, BIN sponsors, processors, stablecoin settlement service providers, and compliance service providers behind the scenes.

The second layer is the infrastructure for stablecoin card issuance. This layer is where Payward's acquisition of Reap is truly directed. Companies in this category include Reap, Rain, StraitsX, Baanx, Immersve, Kulipa, Gnosis Pay, and others. They are not just creating a front-end card product; they are helping wallets, exchanges, fintechs, or enterprise clients launch card projects.

The problems they aim to solve include: how to issue cards, how to connect to Visa/Mastercard networks, how to perform real-time authorizations, how to connect users or enterprises' digital asset balances, how to handle exchanges between stablecoins and fiat currencies, how to set transaction limits, card controls, risk rules, on-chain and off-chain reconciliation, and how to meet compliance requirements in different regions. In other words, what this layer sells is not the card face, but the card issuance capability.

For clients, the ideal situation is: I do not need to find card issuing institutions, BIN sponsors, processors, stablecoin settlement parties, and compliance service providers myself; I can integrate this capability into my product through a set of APIs or a card program. This is why these companies are more like infrastructure.

The third layer is the infrastructure for stablecoin payments, treasury, and settlement orchestration.

This layer does not necessarily start from U cards, but will become the underlying funding flow for U cards, wallets, exchanges, and enterprise payment products. Companies like Bridge/Stripe, BVNK/Mastercard, Fireblocks, Zero Hash, Circle, Conduit, Mural Pay, Sphere, BlindPay, Arf, Yellow Card, Alchemy Pay, etc., can all be included in this observation scope.

The problems they solve are not about "how to issue a card to users," but how enterprises can use stablecoins for receiving payments, making payments, cross-border settlements, on/off-ramps, fund transfers, liquidity management, and on-chain and off-chain reconciliation in compliant scenarios overseas. This capability is also very important for U cards.

Because once a card is swiped, it will definitely involve how funds are settled, how stablecoins are exchanged, how fiat currencies are realized, how accounts in different regions are transferred, and how corporate accounts are reconciled.

Thus, U cards are merely a front-end scenario for stablecoin payments. The deeper issue is: how stablecoins can become a backend settlement asset that can be used by enterprises, platforms, and financial institutions within overseas compliance frameworks.

The fourth layer consists of traditional payment rails, processors, and compliance risk control. This layer is often overlooked by many crypto users, but it is the unavoidable foundation for U cards. It includes card organizations like Visa and Mastercard, issuing processors or card issuing infrastructure companies like Marqeta, Galileo, Thredd, i2c, Paymentology, Enfuce, Adyen Issuing, Stripe Issuing, and KYC/AML and transaction monitoring service providers like Chainalysis, TRM Labs, Elliptic, Sumsub, and Persona.

Without this layer, it would be difficult for U cards to truly achieve "issuance, swiping, settlement, handling chargebacks, and compliance risks." Because what merchants ultimately accept is not an on-chain transfer, but a standard card transaction. It needs to comply with card organization rules, require authorization results, have settlement and clearing, and handle chargebacks, fraud, sanction screening, abnormal transactions, and consumer protection.

This is also why stablecoin payment infrastructure is not simply a Web3 business. It must simultaneously understand crypto, card networks, banks, payment processing, compliance, and local financial systems. It is important to note that this map is not meant to label each company with a fixed tag. The same company may span multiple layers. For instance, Gnosis Pay can be understood by users as a front-end card product, but it also has underlying attributes of on-chain payments and card issuing infrastructure. After Bridge was acquired by Stripe, it has become more like stablecoin payment orchestration and settlement infrastructure. Reap has capabilities in enterprise payments and card issuance, and is also extending into stablecoin treasury and cross-border payments.

Therefore, what this map truly aims to illustrate is that the U card industry is not simply about "whose app looks better"; rather, it is a stack competition surrounding card issuance, settlement, fund management, compliance capabilities, and local financial connections. The higher up you go, the closer you are to users and traffic. The lower you go, the closer you are to licenses, networks, funds, settlements, and risk control. There can be many front-end U card products, but what is truly difficult to replicate is the middle and lower layers that can integrate stablecoin balances into real payment networks. This is why Payward acquired Reap, not just a front-end U card. What it needs to supplement is not just a card face, but a set of payment infrastructure that can be embedded into Payward Services, serving exchange users, enterprise clients, and cross-border capital flows.

Where Do Various Representative Companies Stand?

If we only look at the front-end, many companies can claim they are doing U cards. But if we look at infrastructure capabilities, the differences become very apparent. Some companies are more focused on card issuing infrastructure, some on self-custody wallet cards, some on stablecoin orchestration, and some on regional fiat stablecoin and local payment network connections.

Reap, Rain, and StraitsX are just three representatives among them. Looking outward, we can also see companies like Baanx, Immersve, Kulipa, Gnosis Pay, Bridge, BVNK, Fireblocks, Zero Hash, Circle, Conduit, Mural, and Sphere. They may not all be doing the same thing, but they are all answering the same question: how do digital asset balances enter the real payment and financial systems?

The first category is card issuing infrastructure companies. This category is closest to the main line of U cards. Representative companies include Reap, Rain, Baanx, Immersve, Kulipa, Gnosis Pay, and StraitsX. The problem they solve is: how to enable wallets, exchanges, fintechs, or enterprise clients to issue a card and integrate users' or enterprises' digital asset balances into the card network. The key here is not about "creating a front-end card by oneself."

Rather, it is about whether they can integrate card issuance, BIN sponsorship, real-time authorization, processor connections, stablecoin balance verification, exchanges, card controls, limits, risk control, and compliance requirements into a set of infrastructure. Reap is a very typical example in this category. It does not just create a C-end U card product; it combines enterprise payments, card issuing, cross-border payments, expense management, and embedded finance APIs together. Reap's card issuing page emphasizes a stablecoin-powered card program, Visa cards, digital assets/fiat spending, and real-time authorization, meaning it can perform real-time authorization deductions based on the digital asset balance in the client's ledger.

Rain can also be placed in this category. It emphasizes using a unified API to place accounts, cards, and global money movement on stablecoin rails, allowing enterprise clients not to have to piece together multiple suppliers themselves.

StraitsX is more focused on card issuance and local compliance connections in the Asian market. Its card issuance page explicitly mentions licensed infrastructure, BIN sponsorship, and stablecoin settlement to support stablecoin-backed card programs in the Asian region. The core value of this category of companies is not the card face, but the ability to package the heavy lifting behind the card project.

The second category is self-custody/on-chain native card companies. This category is different from traditional exchange cards. They are more concerned with whether users can enter Visa/Mastercard and other real payment networks from self-custody wallets, on-chain accounts, or smart accounts. Representative companies include Gnosis Pay, Baanx, Kulipa, and Immersve.

For example, Gnosis Pay emphasizes the self-custodial card and on-chain account experience. Baanx has long served wallet card projects like Ledger, MetaMask, and 1inch. Companies like Kulipa and Immersve also emphasize connecting wallets, stablecoin balances, authorizations, and card networks. The core issue for these companies is not "how to spend the exchange balance," but "how to bring the balance in the on-chain wallet into real consumption scenarios." This path is more Web3 native, but also more challenging. Because it not only has to deal with card issuance, authorization, settlement, and compliance, but also has to manage the relationship between self-custody wallets, on-chain accounts, user signatures, on-chain and off-chain accounting synchronization, and transaction experiences.

The third category is stablecoin payment orchestration/enterprise fund flow companies.

This category does not necessarily start from U cards, but will become the underlying funding flow for U cards and enterprise payments. Representative companies include Bridge/Stripe, BVNK/Mastercard, Fireblocks, Zero Hash, Circle, Conduit, Mural, and Sphere.

The problems they solve are not about "how to issue a card to users," but how enterprises can receive, store, exchange, send, and settle stablecoins in compliant scenarios overseas. Bridge is a typical company in this category. Bridge officially describes itself as an end-to-end stablecoin platform, serving enterprises to receive, store, convert, issue, and spend stablecoins; its collaboration with Visa also points to stablecoin-linked Visa cards and allows developers to issue related card products through APIs. After Stripe acquired Bridge, the relationship between these companies and traditional payment networks will become increasingly close. Visa also disclosed in 2026 that Bridge-enabled stablecoin-linked cards have already launched in 18 countries and plan to expand to more markets.

Companies like Fireblocks, Zero Hash, and Circle are more focused on custody, wallet, treasury, settlement, compliance, and institutional-grade infrastructure. They may not all center around U cards as their core product, but if a platform aims to facilitate stablecoin payments, fund transfers, custody, reconciliation, and compliance, they often appear in the underlying tech stack. The core value of these companies is transforming stablecoins into backend financial tools that enterprises and financial institutions can access, manage, and settle.

The fourth category is regional fiat stablecoins/local payment connection companies.

This category leans more towards local markets, local licenses, local payment networks, and connections to local currencies. Representative companies include StraitsX, Yellow Card, Alchemy Pay, Arf, and BlindPay.

They may not all center around U cards, but they all engage in a critical issue: how digital asset balances enter the local financial system. For instance, the value of StraitsX in the Singapore and Southeast Asian markets is not just about card issuance but a combination of local stablecoins, local payment networks, BIN sponsorship, on/off-ramps, and compliance frameworks. Yellow Card is more focused on stablecoin on/off-ramps and local payment connections in the African market. Alchemy Pay is more about crypto-fiat payment gateways and on/off-ramps. Companies like Arf and BlindPay are closer to cross-border payments, payment institution fund flows, and regional market settlements. The barriers for these companies are often not the technology itself but regional capabilities: local partners, local banking relationships, local regulatory understanding, local payment networks, and local liquidity.

So, returning to Payward's acquisition of Reap. Reap is not the only company building stablecoin payment infrastructure. However, it represents a very important asset: an infrastructure company that has already integrated card issuing, corporate payments, stablecoin fund arrangements, cross-border payments, and embedded finance capabilities. These companies do not always stand in the spotlight. They are more like the machines hidden behind card products. Front-end U card brands can focus on user growth, subsidies, card designs, and consumption scenarios. But what infrastructure companies need to solve is whether this card can actually be issued, swiped, settled, and continuously operate under different regions, compliance requirements, and funding paths. This is also why exchanges, wallets, fintechs, and traditional payment giants pay attention to this layer. Because once stablecoin payments truly enter real commercial flows, the scarcest resource may not be a card but the ability to connect cards, accounts, stablecoin balances, corporate fund flows, and local financial systems.

How Do These Infrastructure Companies Make Money?

After understanding where these companies stand, the next question to ask is a more practical one: how do they actually make money?

If it’s just front-end U card products, the business model seems relatively straightforward: users open cards, recharge, spend, exchange currencies, and withdraw, with the platform earning from fees, spreads, card fees, or service charges.

However, infrastructure companies like Reap, Rain, StraitsX, and Bridge are not entirely the same. They often face not individual C-end users but wallets, exchanges, fintechs, corporate clients, payment companies, or other platform-type clients. They are not selling a single card but a complete set of capabilities for card issuing, authorization, exchange, settlement, reconciliation, risk control, compliance, and fund management. Therefore, the revenue of these companies is usually not from a single source but layered and compounded.

The first type of revenue is card program fees.

If a wallet, exchange, or fintech wants to launch its own branded card program, it may not want to find card issuing institutions, BIN sponsors, processors, KYC service providers, risk control systems, stablecoin settlement parties, and local banking partners by itself. It is more likely to choose to connect with an infrastructure service provider.

At this point, the infrastructure company can charge clients setup fees, monthly service fees, account service fees, card project management fees, custom development fees, or fees based on the number of cards, active users, or transaction volumes. For B2B clients, the essence of these fees is: I pay to buy a set of already integrated capabilities rather than starting from scratch.

The second type of revenue is API/SaaS fees.

If the infrastructure company turns card issuing, account management, balance inquiries, transaction event callbacks, authorization control, freezing, exchange, settlement, reconciliation, and compliance monitoring into APIs, it can charge based on call volume, transaction volume, number of accounts, monthly subscriptions, or enterprise packages. This is also why infrastructure companies often resemble platform businesses.

Front-end brands earn from user transactions and consumption behaviors. Infrastructure companies earn from platform clients accessing this set of capabilities.

The third type of revenue is interchange or card issuing revenue sharing.

In card transactions, the fees paid by merchants are distributed among acquiring institutions, card organizations, and issuing sides. For institutions participating in card issuing projects, if the transaction scale is large enough, they may receive a certain percentage of revenue sharing from each transaction. Interchange is not fully accessible to all participants, nor is it the same across all regions, card types, or project structures. How much each party receives depends on card organization rules, regional regulations, card types, issuing institutions, BIN sponsors, processors, program managers, and cooperation agreements. If the infrastructure company plays a key role in the card issuing project, it may participate in the revenue distribution related to card transactions, but the specific proportions and structures depend on the region, licenses, and cooperation arrangements.

The fourth type of revenue is FX spreads and crypto-fiat conversion spreads.

Stablecoin cards often involve conversions between several assets: USDT/USDC, USD, local currencies, merchant settlement currencies, and other assets in user accounts. As long as exchanges are involved, spread revenue may arise.

For example, if a user’s account holds stablecoins, and the merchant transaction currency is Hong Kong dollars, euros, Mexican pesos, Brazilian reals, or other local currencies, it will involve exchange rates, conversion paths, liquidity, and settlement arrangements.

If the infrastructure company provides exchange and liquidity services, it may charge spreads or conversion fees at this stage. But this also depends on specific licenses and compliance structures. Different regions have different regulatory requirements for currency exchange, virtual asset conversion, payment settlement, and fund flows, so it cannot be generalized.

The fifth type of revenue is treasury/settlement service fees.

This part is especially important in B2B scenarios. The real pain point for corporate clients is often not "whether there is a card."

But how to manage funds across multiple regions, how to manage corporate accounts, how to exchange stablecoins and fiat currencies, how to implement cross-border payments, and how to unify management of employee cards, vendor payments, merchant collections, and corporate treasury. If the infrastructure company can handle these issues, it is not just a card service provider but more like a corporate fund flow service provider.

It can earn service fees from cross-border payments, fund transfers, settlement services, account management, corporate treasury, bulk payments, collection distribution, and accounting reconciliation. This is also why companies like Reap are worth watching.

Its significance lies not only in card issuing but in its ability to integrate corporate payments, card issuance, cross-border fund flows, and stablecoin treasury into the same capability stack.

The sixth type of revenue is compliance/risk service fees.

KYC, KYB, AML, sanctions list screening, transaction monitoring, fraud detection, chargeback management, abnormal transaction handling, merchant category restrictions, regional restrictions, user limit management—these may not sound appealing but are crucial in the payment industry. Especially in the intersection of crypto and cards, the difficulty of risk control and compliance is higher.

If an infrastructure company has already turned these capabilities into products, it can charge platform clients compliance and risk-related service fees or bundle this part into the overall card program fee and API fee. From this perspective, compliance is not merely a cost center. In payment infrastructure, compliance capabilities themselves are part of the product capabilities.

The seventh type of revenue is local payment and on/off-ramp service fees.

Some companies do not necessarily rely solely on cards for revenue. They may also participate in local payment networks, local bank accounts, collection accounts, payment channels, on/off-ramps, fiat inflows and outflows, local currency exchanges, and corporate account connections. If a business or platform wants to connect digital asset balances with local financial systems, it may require these services. These capabilities are usually highly localized.

Bank cooperation, payment channels, regulatory boundaries, user habits, and fund flow costs vary across different countries. Therefore, companies that can establish local connections often have strong regional barriers. Here, it is also essential to carefully examine a type of revenue: float or reserve income.

Stablecoin and fiat balances can indeed create space for fund management, but not all companies can benefit from this income, nor are all jurisdictions allowed to do so. How client funds are isolated, who holds the balances, whether they can generate income, who the income belongs to, whether disclosure is required, and whether they are subject to payment licenses, electronic money licenses, trust arrangements, or customer asset protection rules varies significantly. Therefore, it cannot be simply stated that these companies "earn interest from user balances." A more prudent understanding is that these companies’ revenues come from multiple layers of accumulation.

They may earn card program fees, API fees; they may participate in interchange revenue sharing, or earn from exchange spreads, settlement service fees, treasury service fees, compliance and risk service fees, and local payment connection fees. But what type of money each company can earn depends on which layer it stands on, what licenses it holds, what responsibilities it bears, what clients it serves, and which segment of the transaction chain it controls. This is also why the valuation logic of front-end U card brands and infrastructure companies may be entirely different.

Front-end brands focus more on user growth, transaction volume, retention, customer acquisition costs, and consumption scenarios. Infrastructure companies focus more on client quality, API access volume, transaction processing scale, regional coverage, compliance capabilities, banking and card organization relationships, system stability, risk control capabilities, and whether they can be reused by more platforms.

In simple terms: front-end brands earn from user consumption. Infrastructure companies earn from the complexity that has been encapsulated. This is also the logic behind Payward's acquisition of Reap. What it bought is not just a standalone consumer card product but a set of infrastructure capabilities that can serve B2B clients, corporate payment scenarios, cross-border fund flows, and stablecoin back-end capabilities.

If in the future exchanges, wallets, and fintechs all want to bring digital asset balances into real commercial flows, then what is truly valuable may not be who issued a card first, but who can connect card issuing, authorization, exchange, settlement, reconciliation, risk control, compliance, and local financial connections into a replicable, embeddable, and scalable service.

What's Truly Valuable is Not the Card Face, But the Card Back

Returning to the initial question: Why did Kraken buy Reap instead of just getting a front-end U card? The answer is clearer now. If the goal was simply to create a card, there are many brands of front-end U cards available. One could purchase a product that users perceive more strongly, or collaborate with issuing institutions, processors, and BIN sponsors to launch a card.

However, Payward's acquisition of Reap is not about the card face. It is about a complete set of established infrastructure: card issuing, corporate payments, real-time authorization, stablecoin backend settlement, cross-border fund flows, treasury, compliance risk control, and the ability to connect with traditional financial rails. This is also the most commonly misunderstood aspect of the U card industry. Users see just a card.

But what truly makes this card operational are the issuing institutions, BIN sponsors, processors, card organization networks, banking collaborations, local payment channels, stablecoin accounting systems, risk control rules, and compliance frameworks behind it.

Thus, U card growth is merely a front-end phenomenon. What truly matters is who is integrating digital asset balances into real payment networks, and who is creating a replicable infrastructure for issuing, exchanging, authorizing, clearing, settling, reconciling, and ensuring compliance.

This process will not become simpler just because of a card. On the contrary, the deeper one delves into real commercial flows, the more one realizes that payments are not just a front-end function, but a heavy system engineering task. It requires licenses, banking relationships, card organization rules, processor capabilities, local payment networks, compliance frameworks, risk control capabilities, and long-term operational experience.

These elements are slow, cumbersome, and not glamorous. But precisely because of this, they are harder to replicate.

In the past, the most important questions in the crypto world were how to buy coins, how to trade, and how to custody them. Now, a more practical question is becoming important: how are digital asset balances spent, settled, and embedded into real commercial flows? The answers to this question may not come from the front-end brands that excel at card design, subsidies, or user growth. More likely, they will come from the infrastructure companies that connect issuing, settlement, exchange, risk control, compliance, and local financial rails layer by layer.

Therefore, Payward's acquisition of Reap is not just a merger news of an exchange parent company. It is more like a signal: as stablecoins begin to enter payments and corporate fund flows, exchanges, wallets, fintech, and traditional payment companies are competing not just for user assets, but for the control of the infrastructure that allows digital asset balances to enter the real financial system. This is the true role behind the U card.