on
Council Post: Five Critical Questions To Ask When Building Your Payment Strategy
Chuck Yu is CEO of VGS, a trusted infrastructure powering payment tokenization and agentic commerce for the world's leading enterprises.

getty
After nearly two decades in payments, I've fielded many questions about payment strategy. My career has taken me from a payments startup, where I worked with enterprise merchants, to an executive at Visa, where I took on leadership roles across the organization. Every experience has taught me a thing or two about how payments work on a global scale.
Now that I am back at a fintech startup as CEO, I’m answering questions from companies about how to best build their payments strategy. And with the introduction of agentic commerce and stablecoins, payments are only becoming more complex.
One thing I’ve figured out is that the early decisions you make in your payments journey at any company will shape your ability to scale. Before you build (or rebuild), here are five foundational questions worth asking:
1. What is your payment volume?
2. Are your transactions properly structured as CITs or MITs?
3. Are you operating as the merchant of record (MoR) or leveraging an enabler, and what does that mean for liability and control?
4. What payment form factors are you using (cards, PSP tokens, network tokens, wallets) and how will that affect flexibility and security?
5. Who is your payment service provider and what are the differences between options?
These questions shape your payment strategy, and getting them right early prevents future complexity.
1. What is your payment volume? Are you processing a significant volume?
Payment optimization adds complexity and costs, so I always think businesses need to make sure the volume gains are meaningful; improvements are usually measured in basis points, not percentage points.
In agentic commerce, it’s exciting and new, but autonomous purchasing adds complexity in orchestration, identity and routing. If volume doesn’t justify it, early overengineering adds cost with little value.
2. Merchant of record vs. payment enabler: What role are you playing?
One important distinction in payments is defining your business's role. It’s something I’ve had to figure out myself while leading startups, and I often discuss it with others.
You need to answer: Is your business the merchant of record or a payment enabler?
The merchant of record is the legal entity responsible for the transaction. That includes payment acceptance, chargebacks and disputes, refunds and even taxes and regulatory compliance.
If you are the MoR, you own the risk, but you also retain full control over customer relationships and revenue flow.
An example of an MoR company includes Apple. Apple sells directly to consumers, but handles all billing, refunds and disputes in-house.
Your business doesn’t have to be an MoR, though. It can be a payment enabler.
A payment enabler provides payment infrastructure while another entity remains the merchant of record. Payment enablers help businesses accept payments, onboard sellers and manage compliance, while the end business remains the MoR.
Shopify is an example of a payment enabler. Shopify provides the payment infrastructure, but each store running on Shopify’s software remains the MoR.
But it’s important to note that in agentic commerce, AI agents blur the distinctions among orchestration platforms, marketplaces, facilitators and merchants of record. Businesses should and need to define who is responsible for what.
The right, intentional choice of MoR or payment enabler depends on your business. Your MoR structure shapes liability, compliance, expansion and long-term flexibility.
3. What is the form factor of the payment?
Payment methods aren’t just about cards versus wallets. It’s also about how payment credentials are represented and stored.
Common form factors include:
• Personal account number, or “PAN” (raw card): The actual 16-digit card number, requiring PCI compliance.
• Network tokens: Card-network-issued substitutes for PANs that enable secure transactions without storing card data.
• PSP tokens: Provider-issued tokens tied to a specific PSP, reducing PCI scope but limiting portability.
• DPAN/MPAN: Network-issued tokens tied to a specific device (DPAN) or merchant relationship (MPAN). Both let you transact without touching the raw PAN and are invalidated or scoped independently of the underlying card.
• Alternative identifiers: Wallet IDs, bank mandates and similar identifiers operate with separate compliance frameworks.
In agentic commerce, AI agents need delegated permission to transact without repeated logins, increasing the importance of tokenization, authentication, interoperability and secure credential storage.
The payment credential is becoming not just a payment instrument but a permissioning mechanism for autonomous systems.
Each form factor has implications for PCI scope and compliance burden, portability between providers, authorization rates and long-term flexibility.
Understanding what you’re storing and who controls it is critical.
4. Who is your PSP and what are you actually getting?
Not all payment service providers are created equal.
PSPs differ in many ways. For example, they could have different global acquiring covers, network relationships, tokenization models, etc.
Some PSPs are developer-first. Others are enterprise-first. Some optimize for speed; others for cost or reach.
As agentic commerce evolves, PSPs may increasingly differentiate through token management, delegated authority, identity verification and API flexibility.
Your PSP affects acceptance rates, operational complexity and scalability. Choose with your growth plans in mind.
5. MIT vs. CIT: Who is initiating the transaction?
Every payment is either customer-initiated or merchant-initiated. That distinction determines authentication, liability and the likelihood of approval.
CITs, or cardholder-initiated transactions, occur when the customer is actively involved in the transaction. This can be a checkout purchase, when a customer clicks “pay now,” or a wallet-authenticated payment.
MITs, or merchant-initiated transactions, occur without the customer actively present, such as subscriptions and recurring billing, usage-based charges, and no-show or cancellation fees.
However, MITs do require prior customer consent, proper flagging, references to the transaction and compliance with network rules.
Businesses can and often do use both. The distinction matters because each is processed and authenticated differently, affecting approvals, disputes and compliance.
Final Thoughts
A strong payments strategy is built on clear roles, intentional architecture and accurate transaction design. These five questions aren’t just to help you pick tools; they help you avoid costly rework, compliance surprises and growth blockers later on.
Payments may be invisible to users, but the strategy behind them shouldn’t be.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?