Direct Answer
Choose a card solution for your company’s expenses by checking the product category, application conditions and evidence for your spending workflow.
Choose a card solution for your company’s expenses by checking the product category, application conditions and evidence for your spending workflow.
Start with an existing business card solution if your task is paying your company’s bills. Investigate issuing infrastructure when your task includes operating a card program for customers. An application programming interface (API), which connects your software to a service, can support either task. It does not establish who operates the program. Use the questions below to request proof before treating a provider as a fit.
HaiPay publishes this guide and appears among the examples. The comparison uses official documents and product-team information confirmed on 10 October 2026. It does not report hands-on testing. The examples have no recommendation order or shared score. None of the requested supplier demonstrations has been run. This is procurement guidance, not investment, legal or financial advice.
Decide what you are buying before comparing features
Write the purchasing task in a sentence that names the spender and the work involved. For example: “We need company cards for approved software purchases, with records that finance can match to its accounting entries.” That task describes buying a spending service. A second example, “We need to offer cards to businesses using our platform,” adds a different operating question. The examples are illustrative; neither describes an observed customer or an approved application.
Ask who enters the agreement, who receives the cards, and who handles account reviews, disputes and support. If the answers include responsibilities your company has not planned to operate, pause that shortlist. A long feature list will not resolve the missing operating model. Ask for a named product and a written allocation of duties before discussing implementation.
Choose the purchasing route and confirm responsibilities in writing. API availability does not establish who operates the program.
Clarify contractual roles
The card issuing roles guide provides the next step for understanding issuers, processors and program managers. An issuer is the institution that issues the card; a processor supplies transaction-processing technology. A program manager coordinates the agreed activities for a card program. These roles are questions to identify in the proposed arrangement, not titles to assign from a supplier’s name.
Source: Publisher, “Procurement route and role questions” (original illustrative buying framework). “What Is Card Issuing? Do You Need a Card Program?” supplies role context (Source 13). Published 3 October 2026; accessed 10 October 2026.
Separate eligibility from geography and acceptance
Use a short scoping sheet before requesting a demo. Record your legally registered organization, registration country, operating address, industry, intended cardholders, spending currency and merchant use cases. Put the precise product name beside those facts. A business account, a corporate card product and a platform issuing arrangement require separate confirmation. A supported registration country alone cannot answer all three questions.
In this worksheet, reconciliation means matching available card records to your accounting entries. Settlement transfers funds between parties to complete a payment obligation. For settlement currency, ask which currency the proposed arrangement uses for that transfer. Keep these distinctions visible throughout procurement:
Source: Sveriges Riksbank, “What is settlement in central bank money and why is it important?” (settlement terminology only, not supplier processing times). Published 20 February 2024; accessed 10 October 2026; see Source 14.
Layer | What to record | What the answer must not silently become |
|---|---|---|
Applicant entity | Registered organization type, registration and operating address, industry, application evidence | Guaranteed approval because a country appears on a website |
Product access | Named corporate card product or issuing arrangement; permission and account checks and setup conditions | Every product from the same brand being available |
Cardholder and program | Proposed users, residence countries, platform-account country, program region and permitted use | Applicant-country eligibility inferred from a program label |
Payment workflow | Merchant, billing entity, payment currency and settlement currency, recurring charges and required records | A promise that an intended-use label guarantees payment acceptance |
Source: Publisher, “Eligibility scoping sheet” (original procurement method); product-specific official application and configuration evidence is identified in the two tables below, accessed 10 October 2026.
Treat a missing answer as UNKNOWN. It can justify requesting evidence or pausing a purchase decision. It does not justify saying the feature is unavailable. A confirmed missing requirement can rule out fit for your task; keep the supporting response and reviewer’s decision. Conversely, a documented application condition is a condition to check, rather than a statement that your company has passed the review. Preserve both the supplier’s response and its stated exceptions.
Confirm each layer for the named product. Keep unanswered requirements UNKNOWN rather than calling them unsupported.
Existing solutions to investigate for company spending
These are category examples for a document-based shortlist. The rows show what is documented and what your purchasing team still needs to obtain. They do not establish suitability for your entity, merchants or operating process. Ask the provider to confirm the current product terms for your application before relying on a feature description.
Product example | Publicly documented or disclosed scope | Application boundary | Proof to request before selecting |
|---|---|---|---|
Ramp Corporate Cards | Virtual cards, merchant and category restrictions, and approval workflows are documented for company spending. | The U.S. guide requires a U.S.-registered corporation, limited liability company or limited partnership; nonprofits may apply. It also requires at least $25,000 in a linked U.S. business bank account, most operations and corporate spending in the U.S., a qualifying physical U.S. address and an employer identification number. Credit approval remains separate. | Applicable card agreement and application conditions; configured permissions; a redacted expense-record sample and support ownership. |
Airwallex Corporate Cards | The U.S. page describes virtual company cards, virtual or physical employee cards, spend limits and merchant-category restrictions (rules limiting types of merchants). | The page instructs applicants to open an account, complete identity verification and fund the account. Its list of registration countries supported for business-account applications includes the U.S.; that list does not establish approval for this card product. | Entity-specific account and card approval requirements; which card type and permissions the proposed service includes; a usable reconciliation sample. |
HaiPay | Product-team information describes enterprise U.S.-dollar virtual cards, reusable and single-use cards, dashboard limits and card controls, transaction records, comma-separated-value exports and tags. | Companies registered outside mainland China may apply, subject to industry restrictions and case-by-case review. U.S. and Singapore programs include Visa and Mastercard for advertising spending and artificial intelligence procurement use directions. The Hong Kong program is Mastercard for advertising spending. Program region is not applicant eligibility or an acceptance guarantee. | Current application and industry conditions; the selected program; exact dashboard and API operations; record fields, written fees and support responsibilities. |
Source: Ramp, “Qualifications to apply for Ramp (U.S. based)” and “A corporate card designed for modern finance.” (U.S. application conditions and documented controls). Airwallex, “Set spending limits per transaction” and “Eligible Countries and Territories” (U.S. product and business-account application scope). Publisher product team, “Enterprise card information” (publisher’s product-team confirmation dated 10 October 2026, not independently tested). Official pages accessed 10 October 2026; see Sources 1–4.
For the publisher’s offer, confirmed API capabilities include card creation, freezing and unfreezing, transaction queries and webhook notifications. A webhook is a notification sent to your software when an event occurs. Sandbox access, which provides a test environment, is enabled by the service provider. Confirm the selected operations and test access with the provider; dashboard limits do not establish that limits can be supplied when creating a card through the API.
Source: Publisher product team, “Enterprise card information” (existing operation-level confirmation, reviewed 10 October 2026; no public self-service sandbox or API-create-with-limit claim).
Issuing infrastructure: a separate boundary check
Use this table if the task includes offering cards through your own product or operating a customer card program. It is included to prevent choosing a different service merely because it has card APIs. The entries can have other use cases; the table does not define each provider’s only role. If your requirement is simply paying company bills, return to the existing-solution questions first.
Product example | Documented role or arrangement | Condition or unresolved boundary | Procurement consequence |
|---|---|---|---|
Stripe Issuing | Its overview documents U.S. commercial issuing (issuing cards for business use) and card-program integration. Its U.S. product explanation says the role can be program manager or issuer processor, depending on the support needed. | Live access requires an eligibility review. U.S.-based accounts for this product require physical U.S. presence. Overview and support pages describe regional and product scope differently; this guide makes no combined global country count. | Request approval for the actual entity, use case and account configuration, plus the issuer and responsibility allocation. Test access does not establish live approval. |
Marqeta | The platform provides issuing and processing technology and states it is not a bank. A separate managed option provides program management. | The managed guide describes a statement of work defining services and responsibilities. It also includes a pre-approval review, issuing-bank approval and card-network approval. Its security guidance retains customer responsibilities. Applicant eligibility and exact retained duties remain unconfirmed here. | Determine whether the proposed service is processor-only or managed. Obtain the statement of work, issuer arrangement and task-by-task duties; do not infer automatic approval or removal of client obligations. |
Airwallex Issuing | Its documentation covers commercial-card APIs and a platform example with connected accounts (accounts linked to a platform), cardholder account checks and setup and embedded card management. Its solution guide covers a business’s own spending and use cases for its customers. | Product configuration and account permissions matter. Account checks and setup for the corporate card product does not establish approval for the platform product. A documented platform example is not approval for your company or connected accounts. | Confirm the selected issuing solution, platform and connected-account regions, cardholder conditions, controls and retained responsibilities. An API alone does not determine which path you are buying. |
Source: Stripe, “Issuing,” “How to apply…,” “Physical presence requirement FAQ” and product role disclosure (U.S. commercial scope). Accessed 10 October 2026; see Sources 5–8.
Source: Marqeta, “The platform purpose-built for modern card issuing and processing” and “Guide to Program Management” (technology and managed conditions). Its “Shared Responsibility Matrix for PCI DSS 4.0.1” documents retained security scope. PCI means Payment Card Industry; DSS means Data Security Standard. The program management guide was published 10 June 2025. Accessed 10 October 2026; see Sources 9–10.
Source: Airwallex, “Platform issuing infrastructure for businesses” and “Choose your issuing solution” (configuration-specific use cases). Accessed 10 October 2026; see Sources 11–12.
Send these twelve screening questions before booking a demonstration
Send the same questions to each candidate within the relevant path. Ask for the exact product, a dated answer and a document reference. Assign a reviewer for each response. Finance should own the records and commercial terms; operations should own support and permissions. Your technical and security reviewers should own the questions that depend on integration or data handling.
The questions below are an original procurement worksheet. They are not a claim that every provider supplies each requested feature, document or contractual commitment. Mark an item not applicable only after recording why it is outside your purchasing task. Keep unanswered items visible instead of converting them into a score.
ID | Question to send | Evidence and review task |
|---|---|---|
E01 | Can this exact legally registered organization apply for the named product? Which registration, legal-form, address, industry and review conditions apply? | Obtain the current application requirements and written product identification. The procurement owner checks the proposed entity against each condition without calling the result an approval. |
E02 | Which countries matter for the applicant, platform account, cardholders and card program? Which currencies and merchant-use restrictions apply? | Request a product-specific scope statement that separates these layers. Record whether each answer concerns account checks and setup, issuance or spending rather than copying one country list into every field. |
E03 | Are we purchasing an existing spending solution, processing, program management or another agreed service? Who is the issuer? | Ask for the proposed agreement and responsibility diagram. Identify each contractual party and task owner. For a confidential proposal, keep the documentation in your private procurement record. |
E04 | If we operate a program, which identity checks, anti-money-laundering reviews, fraud handling, disputes, support and security duties remain ours? | Request a responsibility matrix and the relevant contractual scope. Your legal, compliance and operations reviewers check the retained duties. For an existing spending solution, record why this program-operation question is not applicable. |
E05 | Which controls can administrators apply through the dashboard, and which are available through the API? What permissions and exceptions apply? | Obtain an operation matrix and request demonstrations of the controls you require. Record creation, limits, freezing, unfreezing and closure separately; one confirmed action does not prove the others. |
E06 | What restrictions apply to our exact merchants, billing entities, currencies and recurring purchases? | Give the provider a redacted use-case list and request applicable rules. Intended-use descriptions do not prove acceptance. Record unresolved cases without claiming that a transaction will succeed. |
E07 | What charges and commitments apply to the proposed service, including setup, recurring fees, minimums, cards, currency conversion, disputes and exit? | Ask for an itemized, dated quote with its scope and assumptions. Finance checks the same purchasing scenario across candidates. Leave missing prices blank; do not construct a fee comparison from incomplete terms. |
E08 | Who handles an urgent decline, a refund question or a dispute? Which channels, hours and contractual commitments apply? | Obtain a named escalation route and the relevant support terms. Operations checks whether an incident has a responsible owner and how the handoff reaches finance or technical staff. |
E09 | Can finance match authorization, settlement, reversal (undoing an earlier payment step), refund and currency-conversion records to our project and accounting identifiers? | Request a redacted record sample and field definitions. Authorization is the approval stage; settlement transfers funds between parties to complete a payment obligation. Verify how later reversals and refunds connect to the original transaction. |
E10 | Which technical operations are enabled for this product, and how are sandbox and production access approved? | Request access conditions and operation-specific documentation. Your technical reviewer records notifications, keys or secrets used to access the service, errors and permissions. Where automation is unnecessary, document the dashboard workflow instead of making an API a requirement. |
E11 | Who can view card details, manage access and hold integration keys or secrets used to access the service? What data-security duties apply to our arrangement? | Request permission documentation and the applicable security responsibility statement. The security reviewer checks the chosen configuration. A generic security badge does not answer the scope of your own data handling. |
E12 | If we operate a program, how are balances, authorization decisions, settlement and moving the program to another arrangement or exit handled? | Obtain the operating model and exit terms. Finance and technical owners review the program lifecycle. For company spending, keep the simpler account and records questions and explain why moving the program to another arrangement is outside scope. |
Source: Publisher, “Twelve-question supplier pre-screen” (original procurement worksheet; not provider responses or observed customer quotations), prepared 10 October 2026.
Use E01–E03 to resolve category and application scope before spending time on integration demonstrations. Continue with the controls, support and record questions that matter to your actual workflow. For example, a finance-led purchase may require an understandable export before an engineering team needs notification details. That is a task-based review sequence, not a recommendation to accept incomplete security or commercial terms.
Use eight demo requests and record what was actually shown
Give the supplier a written scenario, the evidence you want to retain and the reviewers who need to attend. Ask permission before saving a recording or a sample. Use synthetic or appropriately redacted data rather than live card details. A demonstration record should distinguish documentation, an observed action and a contractual promise; these are different forms of evidence.
All eight requests below are NOT_RUN in this guide. They identify what a buyer can request. A provider may need to explain why an operation is unavailable or outside the proposed service. Do not record a successful test based on a sales presentation that only describes a feature.
ID | Requested demonstration | Evidence to keep | Status |
|---|---|---|---|
D01 | Show the prerequisites, permission and result for creating a card in the proposed product. | Product and environment identity, permitted reviewer access, and a redacted result. Confirm whether the demonstration uses a sandbox or live service. | NOT_RUN |
D02 | Show the specific spending controls your team requires through each proposed interface. | Operation and permission matrix, observed states, and documented exceptions. Keep dashboard and API evidence separate; do not presume identical behavior. | NOT_RUN |
D03 | Show an authorization and decline example, explain the available reason information, and identify the incident owner. | Redacted records, stated reason meanings and escalation path. A reason displayed by the service is evidence to interpret, not proof of the underlying merchant’s decision. | NOT_RUN |
D04 | Show freezing, unfreezing and closure, including who may perform each action. | State definitions, permissions and documented timing or exceptions. Request an explanation for pending and later transactions rather than assuming a control ends every obligation. | NOT_RUN |
D05 | Show how finance follows a payment through the available lifecycle records and export. | Matched identifiers, field definitions, query or export sample, and treatment of a reversal or refund. Record missing links for further investigation. | NOT_RUN |
D06 | If an API is needed, explain and demonstrate the documented notification and error-handling behavior. | Applicable documentation and controlled examples for duplicates, retries and ordering. Do not improvise financial recovery instructions when the contract does not define them. | NOT_RUN |
D07 | Walk through a dispute or urgent support escalation with the relevant teams. | Named owners, handoff points, channels and agreed terms. Label a walkthrough as a walkthrough; it is not evidence that a real incident met a promised response time. | NOT_RUN |
D08 | If operating a program, show the issuer arrangement and the duties retained by your organization. | Proposed responsibility matrix, contractual scope and unresolved approvals. An explanation is evidence for review, not a completed approval or legal assessment. | NOT_RUN |
Source: Publisher, “Eight supplier demonstration requests” (original buyer worksheet; no supplier demonstrations conducted), prepared 10 October 2026.
Turn responses into a review record, not a ranking
Keep a record for each requested answer: product, purchasing path, question, response status, document reference, responsible reviewer and review date. The supplied proof recorder organizes those fields. It does not decide that a supplier meets your requirements. Its example inputs are synthetic; software checks of the recorder do not test any card provider.
A synthetic example: your team asks for refund-to-payment matching and receives no sample. Record UNKNOWN, assign finance to request the missing fields, and leave supplier fit undetermined. If the provider later sends a sample, record it as a documented response awaiting validation. Only your reviewer can assess whether that evidence answers the requirement for the chosen product.
Request, record, review and follow up. Documentation is not an approval, and none of this guide’s requested supplier demonstrations has been run.
Source: Publisher, “Procurement proof recorder and synthetic example” (original workflow asset, not customer or supplier-test results), prepared 10 October 2026.
Build the next shortlist from the unresolved purchasing decisions. If the product category is wrong, request a different product or stop evaluating that proposal. If an essential capability remains unknown, ask for evidence and a reviewer decision before contracting. If an answer concerns another entity or configuration, keep it as context rather than treating it as proof for yours.
When you are ready to inquire about an existing enterprise virtual-card option, use the business card product page. Bring your entity details, spending workflow and required records. Technical implementation and advertising billing need their own follow-up assessments; the planned API guide and advertising guide remain separate editorial proposals until their pages are available.
Sources
Official pages were accessed on 10 October 2026. They support the specific documented scope above, not supplier approval or hands-on performance. The publisher’s product information is disclosed separately in the relevant source lines; no independent test or public-document certification is claimed.
- U.S. application conditions — entity, cash, address, operations and identification conditions. Accessed 10 October 2026.
- Corporate card product documentation — virtual cards, controls and credit-approval disclosure. Accessed 10 October 2026.
- U.S. company and employee cards — card types, controls and account checks and setup sequence. Accessed 10 October 2026.
- Business-account application countries — business-account registration-country scope only. Accessed 10 October 2026.
- Commercial card-program overview — U.S. commercial issuing scope. Accessed 10 October 2026.
- Applying for live program access — eligibility review distinct from test access. Accessed 10 October 2026.
- Physical presence requirements — physical presence requirement for U.S.-based accounts. Accessed 10 October 2026.
- U.S. product role disclosure — program-manager or processor role depends on support needed. Accessed 10 October 2026.
- Issuing and processing platform and program management guide — technology role, managed option, statement of work and approval conditions. Published 10 June 2025 (program management guide); accessed 10 October 2026.
- PCI responsibility matrix — retained customer and bank-facing security responsibilities. Accessed 10 October 2026.
- Platform issuing configuration — connected-account example and cardholder account checks and setup. Accessed 10 October 2026.
- Choosing an issuing solution — first-party and third-party uses; configuration-specific permissions. Accessed 10 October 2026.
- Role and program guide — issuer, processor and program-manager roles and program responsibility questions. Published 3 October 2026; accessed 10 October 2026.
- Settlement terminology — funds transfer and settlement obligations; not a claim about any provider’s timing or accounting fields. Published 20 February 2024; accessed 10 October 2026.
FAQ
Keep the feature unknown until you obtain a product-specific response. Your team can pause selection for an unmet evidence requirement, without claiming the supplier lacks the feature.
Check what the list covers. Account checks and setup, a card product, a platform arrangement and cardholder access are separate questions. Request conditions for your company and the proposed product.
A software interface can automate a company’s own spending or support a platform arrangement. Identify the service and contractual responsibilities before assigning the program-operation role.
Obtain the current application requirements and written product identification. The procurement owner checks the proposed entity against each condition without calling the result an approval.
Ask for the proposed agreement and responsibility diagram. Identify each contractual party and task owner. For a confidential proposal, keep the documentation in your private procurement record.
Ask for an itemized, dated quote with its scope and assumptions. Finance checks the same purchasing scenario across candidates. Leave missing prices blank; do not construct a fee comparison from incomplete terms.
Related HaiPay surfaces
Explore the payment stack
Guide
Card issuing roles
Understand the roles involved in a card program.
Product
HaiPay card issuing
Discuss product scope and your business requirements.
Glossary
Issuing bank
Read the definition of the institution that issues a card.
Need help mapping your payment stack?
Talk to HaiPay about acquiring, orchestration, local methods, and payout workflows.
Contact us