Questions ISVs Should Ask About Payment APIs in 2026

Every "best payment API" ranking scores the same things: documentation, SDK languages, a pricing table. Those are fair criteria for a developer adding a checkout to their own shop. They are the wrong criteria for an independent software vendor, because an ISV is not the merchant. Your customers are. You are choosing an API payment platform that hundreds of other businesses will be onboarded to, priced on, branded with and supported through, in a store and online, for years.

So this is not a ranking. It is the list of questions we would ask if we sat on your side of the table, written for the CTO or lead developer who has to integrate the thing and the product lead who has to live with the contract. Each question comes with why it matters, what a good answer sounds like, and the red flag that should slow you down. Put them to every provider on your shortlist, us included, and ask for the answers in writing.

Key Takeaways: Questions ISVs Should Ask About Payment APIs

• For a developer integrating payments into one business, documentation and SDK quality decide most of the outcome. For an ISV, the platform model decides it: merchant onboarding through the API, pricing you control, branding you own, and one integration for in-store and online.
• The fastest honest test of any payment API is whether your team, or your coding agent, can reach a verified test transaction in a day without a sales call.
• "Omnichannel" is a claim. One order object, one customer token, one webhook schema and one settlement report across the terminal and the checkout is a fact you can check in the API reference.
• Ask what happens to your integration when the provider releases a new terminal. The common answer in this industry is "a new integration". The right answer is "nothing".
• Ask how payment methods are contracted and switched on. A platform where every method sits on one agreement and can be activated from a portal or an API saves weeks per merchant.
• Ask about failure and exit before you ask about price: offline behaviour, webhook retries, incident history, acquirer lock-in and token portability.

What payment solutions are recommended for developers who want to integrate via API?

The short answer depends on what you are building, and the recommendations sort cleanly into three groups.

You are adding payments to your own online product. Stripe is the usual recommendation for a reason: the strongest developer experience in the industry and the most complete billing product. Adyen, Checkout.com and Mollie are the common alternatives, Adyen and Checkout.com for larger merchants, Mollie for European online businesses.

You need in-store and online through one API. The list is shorter. Adyen, Stripe and Surfboard Payments each expose terminals, online checkout, tokenization and recurring charges through a single integration. Most other providers either cover one channel or sell two products under one logo.

You are a software vendor embedding payments for your customers. This is a different purchase, and it is where generic rankings mislead. You need a platform model on top of the API: Adyen for Platforms, Stripe Connect, or Surfboard Payments, which was built for ISVs from the start rather than extended to them. The twelve questions below are how you tell those options apart for your product.

How do you find an API-based payment platform tailored for ISVs?

Look for four capabilities that a merchant never needs and a software vendor cannot work without. Any provider that has all four publishes them in its API reference, so you can check before you book a meeting.

• Merchant onboarding as an API. Creating a merchant, running know-your-business checks and going live happens from your signup flow, not from a PDF your sales team chases.
• Pricing you set. You define what each merchant pays and keep the margin, rather than receiving a referral fee on a price list you do not control.
• White-label on every surface. The terminal screen, the receipt, the checkout and the merchant portal carry your brand.
• One integration for every channel. In-store terminals, phones acting as terminals, online checkout and recurring charges share one order API and one customer token.

If a provider's partner story is a reseller agreement and a login to a partner portal, it is a sales channel, not a platform for software vendor payments. The questions that follow test each of the four in detail, plus the things that only show up after go-live.

Questions about developer payment integrations

1. Can we reach a test transaction in a day, without talking to sales?

Why it matters. How a provider treats an unknown developer on day one is how it will treat your engineers for the life of the integration. Gated sandboxes and "request access" forms predict slow support later.

A good answer. Self-service signup, API keys for a demo environment immediately, a reference published as OpenAPI, and guides organised by what you are building rather than by endpoint. Surfboard Payments' getting started guide covers the first hour: developer account, team invites, keys, the demo and live environments, and the path of guides for your use case.

2. Can our coding agent do the integration?

Why it matters. In 2026 much integration code is written by an agent with a developer reviewing it. Documentation written for people reads badly to an agent: it crawls a navigation tree, guesses which guide applies, and invents the payload shapes it cannot find.

A good answer. The provider publishes machine-readable documentation, a Model Context Protocol server for searching it, and installable agent skills, with guardrails that keep the agent in a test environment and away from card data. At Surfboard Payments the whole handoff is one line:

fetch https://surfpay.ai

The root of surfpay.ai serves an integration brief written for machines: the skills to install, the MCP server to connect, the one manual step (a person collects Demo API keys, because issuing credentials means accepting terms), and a verified test transaction to finish on. It works with any agent that can fetch a URL and run commands.

3. Is in-store and online literally the same API?

Why it matters. Most merchants using your software take money in more than one place: a deposit online and the balance at the counter, a webshop beside the store, a kiosk beside the till. If those are separate products, you build and maintain two integrations and reconcile two data models.

A good answer. One endpoint creates an order whether it will be paid at a terminal, on a hosted page or with a stored token. Webhooks carry the same event names on every channel, and settlement is one report. Surfboard Payments uses one order object with a channel field that switches between in-store, online and unattended, which is what unified commerce means in practice.

4. Does one customer token work at the terminal, online and for recurring charges?

Why it matters. Memberships, care plans, tabs and repeat orders all depend on recognising a customer across channels. Without a shared token your merchants ask for the same card twice.

A good answer. A card tapped at the counter can be charged later online or on a schedule, and the token survives a reissued card. Surfboard Payments provisions network tokens through Visa and Mastercard, so the same token works across channels and updates automatically when the card is replaced. The recurring payments guide walks through the merchant-initiated lifecycle.

5. What ends up in our PCI DSS scope?

Why it matters. Every surface where your code touches card data is an audit you pay for every year. The integration pattern decides that, not the provider's own certificate.

A good answer. Card capture happens on the terminal, on a hosted payment page or in the provider's SDK, and your servers only ever see order ids and tokens. A good platform offers both a hosted payment page and a self-hosted checkout from the same order API, and tells you plainly what each does to your scope.

Questions about payment solutions for ISVs: onboarding, pricing and brand

6. Can we onboard a merchant end to end through the API?

Why it matters. Onboarding is where embedded payments are won or lost. If it takes three weeks and a paper form, your conversion from "interested merchant" to "processing merchant" will disappoint you, and your support team will carry the wait.

A good answer. Your signup flow creates the merchant, the platform runs KYB against the company registry, and stores, terminals and branding are configured in the same flow with status delivered by webhook. Surfboard Payments offers programmatic merchant onboarding with KYB built in, and our record from signup to a first live transaction is five hours.

7. Who sets the merchant's price, and who keeps the margin?

Why it matters. This is the difference between payments as a feature and payments as a revenue line. A referral fee pays you once. A margin on every transaction pays for as long as the merchant stays.

A good answer. You define pricing plans per merchant, store or terminal, choose fixed or interchange-plus models, and the platform handles invoicing and settlement deductions. That is what Surfboard Payments' Billing API does. Blended price lists are easy to explain and leave little room for a platform margin unless you negotiate a custom agreement.

8. Whose brand is on the terminal, the receipt and the checkout?

Why it matters. Your merchants chose your software. Every surface that shows another company's logo teaches them that payments are a separate product they could buy elsewhere.

A good answer. Terminal screens, receipts, hosted checkout, merchant portal and customer emails all carry your name and colours, set once through the API and applied to every merchant under your account, as the partner branding guide describes. Surfboard Payments' white-label system covers every customer-facing surface with no "powered by" line.

9. Which payment methods are on the same contract and payout, and how do we switch them on?

Why it matters. Cards are the baseline everywhere. The local methods are where conversion is decided, and they are also where paperwork multiplies: a separate agreement for American Express, another for each wallet, a different settlement for each.

A good answer. Every method sits on one merchant agreement and lands in one payout and one report, and activating a method is a setting rather than a project. On Surfboard Payments, cards including American Express, wallets, Swish, Vipps, MobilePay, Klarna and the rest share one contract and one settlement, and a method can be activated from the Partner Portal, from the Merchant Portal, or programmatically through the Payment Methods API. See the full list of supported payment methods.

Questions about hardware, failure and lock-in

10. Does every terminal run on the same integration, including the ones not released yet?

Why it matters. In-store is where platforms differ most, and it is where ISVs have learned to expect the least. The industry norm is that one provider sells several terminals and each family comes with its own SDK, its own integration and its own certification cycle. We regularly meet software vendors who integrated a terminal, shipped it to their merchants, and then had to build the integration again from scratch when the manufacturer released the next model. That is engineering time spent standing still, and it repeats with every hardware generation.

A good answer. The terminal is a target of the API, not an integration of its own. You create an order, name the device it should be paid on, and the same request works whether that device is a handheld, a terminal with a printer, a self-service kiosk, an unattended module or a phone. At Surfboard Payments there is one integration altogether: every device runs the same payment application against the same API, and our commitment is that no new terminal release will require a new integration. When we add a device, your existing code already supports it.

Today that covers a range led by the handheld SurfTouch Pro and the SurfPrint Pro with its built-in printer, alongside self-service and unattended devices, plus Tap to Pay on iPhone and CheckoutX for Android for merchants who want no dedicated hardware at all. Getting devices to merchants is part of the same API too: terminal ordering and returns are API calls with shipment tracking by webhook.

11. What happens when something fails?

Why it matters. Networks drop, endpoints time out, clouds have bad days. How the platform behaves then is what your merchants will remember.

A good answer has three parts, and you should ask for each.

• At the terminal. Payments continue when the connection does not. Surfboard Payments supports offline payments in a standalone mode and a mode driven by your POS, with encrypted storage on the device, automatic sync, and limits you configure per transaction and in total.
• In your event pipeline. Webhooks are signed, retried and safe to process twice. Ours are delivered up to three times, with retries after five and ten minutes, an alert email on the first failure, and a documented idempotency key: the combination of orderId and paymentId.
• In the platform. Ask how it is hosted and ask for twelve months of incident history. Surfboard Payments runs PCI DSS certified infrastructure across three cloud providers at once, with 99.99 percent uptime.

12. Are we locked to one acquirer, and what does leaving look like?

Why it matters. Most platforms tie you to their own acquiring. That is convenient until pricing changes, authorisation rates drop, or you expand into a market where another acquirer is simply better.

A good answer. An acquirer-agnostic platform lets the processing relationship change without a re-integration, and the contract states what happens to your merchants' stored tokens if you leave. Read for minimum monthly invoices, terminal rental periods and early-termination fees while you are there. Surfboard Payments is acquirer-agnostic by design.

Scorecard: what to bring to the call

Score each answer as published, confirmed in writing, or promised. Only the first two count. "On the roadmap" is a no with a date attached.

In Conclusion: Choosing an API Payment Platform as an ISV

A payment API is easy to like in a demo. The decision an ISV is actually making is about everything around the API: whether merchants can be onboarded without a person in the loop, whether you control the price and the brand, whether the terminal and the checkout are one system, and whether the platform is honest about failure and exit. Those answers are all checkable before you sign, most of them from public documentation.

Take the twelve questions to every provider you are considering. If you want ours in writing, ask us. If you would rather let the code answer, hand your agent one line: fetch https://surfpay.ai

FAQs about Payment APIs for ISVs

What is an API payment platform?

An API payment platform exposes payment acceptance as programmable building blocks, such as orders, payments, tokens, merchants, terminals and settlements, rather than as a finished checkout or a standalone card terminal. Software companies use it to build payments into their own product. For ISVs, the platform should also include merchant onboarding, partner-set pricing and white-label branding.

What payment solutions are recommended for developers who want to integrate via API?

For online payments in your own product, Stripe, Adyen, Checkout.com and Mollie are the usual recommendations. For in-store and online through one API, the shortlist is Adyen, Stripe and Surfboard Payments. For software vendors embedding payments for their customers, compare Adyen for Platforms, Stripe Connect and Surfboard Payments, which is built specifically for ISVs.

How is a payment platform for ISVs different from a merchant payment provider?

A merchant provider serves one business. A platform for ISVs serves a software company and all of its customers, so it adds sub-merchant onboarding with KYB through the API, pricing the software company sets, white-label branding across terminals and checkout, and reporting across the whole merchant base.

How long should a payment API integration take?

A first test transaction should take less than a day. A production integration covering one channel typically takes one to two weeks, and more when you add terminals, onboarding and billing. If a provider cannot get you to a test transaction quickly and without a sales call, expect the rest to be slow as well.

Can an AI coding agent integrate a payment API?

Yes, if the provider publishes documentation an agent can use and keeps the agent inside a test environment. Surfboard Payments serves a complete integration brief at surfpay.ai, with installable agent skills and an MCP server. The agent works against the Demo environment with test cards, never handles card data, and a person collects the API keys.

Does a new payment terminal require a new integration?

With many providers, yes. Terminal families often ship with their own SDK, so a new model means a new integration and a new round of testing. It does not have to. On Surfboard Payments every terminal, SoftPOS app and unattended device runs the same payment application against the same API, and the commitment to partners is that no new terminal release will require a new integration.

Do ISVs need both in-store and online payments from the same provider?

If your merchants take money in more than one place, yes. One provider with one API means one integration, one customer token across channels, one settlement report and one onboarding per merchant. Two providers mean two of each, and the reconciliation between them becomes your work.

How do ISVs make money from embedded payments?

Through a margin on each transaction rather than a one-time referral fee. The platform should let you define the merchant's pricing, fixed or interchange-plus, and deduct your share at settlement. Ask to see the billing configuration, not just the revenue share percentage.

What does acquirer-agnostic mean?

It means the payment platform is not tied to a single acquiring bank. Processing relationships can be added or changed without rebuilding your integration, which protects your merchants' pricing and authorisation rates and makes it easier to expand into new markets.