Reviewed by Mayer Hyman, Payments Specialist | Reviewed for accuracy July 2026
Key Takeaways
- A sandbox account gives software developers a demo environment to code, build, and test payment integrations before going live in production.
- Software vendors that build in-house payments often stretch themselves thin; embedding a payments partner with dedicated expertise typically produces a more reliable result.
- Relying on multiple open gateways or redirecting users to third parties creates integration overhead, weaker acquirer certification, and higher decline rates over time.
- A single MID (merchant ID) and one gateway account can support card-present, card-not-present, and multi-currency processing without separate sign-ups per environment.
Where Payment Integrations Actually Start
A sandbox account is a demo environment where software developers can code, build, and test a payment integration before it goes live in production. Most of the best software products get built and stress-tested this way first — unicorn startups don’t come from nowhere. It’s where the real groundwork for a solid payments integration happens.
The context here is software as a service (SaaS) and independent software vendors (ISVs) building applications that need embedded payments.
Software Innovation Raises the Bar for Payments
Universal SaaS adoption has raised user expectations: end users and the businesses using this software increasingly expect one flexible, customizable application rather than a patchwork of disconnected tools. That shift has followed SaaS into nearly every vertical and market — membership management, campaign management, retail, lodging, wholesale, and niche point-of-sale systems alike.
For ISVs whose downstream users handle monetary transactions with their own customers, the practical question becomes: what happens when those users want to add payment capabilities?
Pairing Software Solutions with Payment Technology
Adding payment functionality can range from simple one-click payments to complex, multi-rail systems. Software companies used to redirect users to third parties for this, and some tried building in-house payments to stay competitive — often spreading themselves too thin and losing focus on their core software expertise in the process.
Today, software companies can instead leverage existing payment processing infrastructure and payment APIs to offer customized, omnichannel integrated payment processing. When an ISV partners with a payments provider that brings dedicated expertise, the result is embedded payments: processing converges directly with the business management application, with no redirect required — payments are accepted inside the software itself.
Reducing Payment Friction in Your Integration
One of the most important elements of a strong payment offering is reducing friction. Software developers with limited payments expertise often default to whatever integration is fastest to ship — a single open gateway, or several stitched together.
That approach seems attractive at first, but it tends to create real barriers over time: loss of control over the user relationship, ongoing maintenance across multiple vendor integrations, and weak support when something breaks. Many open gateways maintain more connections than their bandwidth can properly support, and outdated acquirer certifications on their end can translate into higher decline rates for your users because less data gets passed through to acquiring banks and card issuers. These gateways also tend to lack functionality for evolving needs — for example, supporting multiple currencies often requires a separate gateway ID for each one.
These options can get your users accepting ecommerce payments, but they’re often limited in functionality beyond that baseline. Businesses evolve alongside their customers and need pricing flexibility and global, omnichannel payment functionality that scales with them.
A Two-Pronged Approach to Integration
Some software companies need to keep working with open gateways for their existing users, and that’s a reasonable starting point. As an Elavon payments partner, Cartis supports software companies and their users in maintaining their current gateway relationship — no software changes required — while still improving their credit card processing options. Even without adopting Elavon’s own gateway, Converge, directly, integration is possible through pre-established value-added-reseller relationships and direct-to-host connections into Elavon for processing, regardless of which gateway a user currently relies on.
The second approach is making payment integrations seamless and simple from the start. Whether you’re integrating payments into a SaaS product, an existing ecommerce platform, a mobile app, in-person terminals, or web forms, Elavon’s Tetra Semi-Integrated Solution and Converge omnichannel gateway support integration through payment APIs and SDKs — including a single API for both card-present and card-not-present acceptance across North America.
Common Integration Questions from ISV Partners
The questions below reflect real obstacles raised by SaaS providers and ISV partners evaluating a payments integration. They’re a useful checklist for evaluating any payments partner, not just one specific vendor.
Developer Tools and Testing
What developer tools are available for testing?
Look for a dedicated solution engineer for ongoing support, a developer portal, sample code, and a demo/sandbox account with API credentials and demo devices where applicable.
Are card-present terminals and readers available for card-present rates?
Many gateway integrations don’t offer card-present hardware. Look for a partner offering smart terminals, EMV PIN pads, and EMV card readers that work standalone or integrate directly with your software.
Integration Methods
What custom payment integrations are typically supported?
For web and mobile app payments, expect a payment gateway integration with options like a hosted payment page, Lightbox, Checkout.js, or an XML API. For desktop or mobile point-of-sale card-present payments, look for an SDK integration if tokenization is required, or terminal semi-integration if it isn’t. Travel, entertainment, and property management systems typically need their own dedicated gateway integration path.
What about existing shopping cart or CMS platforms?
A solid payments partner should offer simple integration paths for platforms like WooCommerce, Magento, and BigCommerce, ideally through pre-established plugin relationships.
What mobile wallet support is available?
Look for direct support for Google Pay and Apple Pay on web checkout flows.
Compliance and Coverage
How do we stay within PCI guidelines?
A good partner will walk through which integration methods put your application in PCI scope (handling primary account number data directly) versus which methods let you offload that scope entirely.
Can the same provider serve both Canadian and US merchants?
This varies by provider — confirm dual-market support before committing if your users span both countries.
What card brands and international schemes are supported?
Confirm support for all major card types — Visa, Mastercard, American Express, Discover/Diners, JCB, China UnionPay, and Interac for Canadian card-present transactions — plus a straightforward Amex onboarding path, since Amex acceptance is often the most cumbersome part of merchant setup with legacy providers.
Funding and Reconciliation
How fast is funding, and does it solve reconciliation headaches?
Ask specifically about same-day funding cutoffs and whether faster options (next-day, fast-track, or instant funding) are available. Also ask whether the provider offers gross deposit funding — where you receive 100% of the amount charged daily, with fees withdrawn separately on a set schedule — since net-fee structures are one of the most common reconciliation complaints ISV partners raise.
What reporting tools are available outside our own software’s reporting?
Look for complimentary access to a reporting portal for daily settlements and deposits, independent of whatever reporting your own software already provides.
Is pricing flexible — fixed rate, interchange-plus, or a choice?
A partner who can structure either model competitively, based on your downstream clients’ actual volume, gives you more room to negotiate good outcomes for your users.
Onboarding and Partnership
What does merchant onboarding actually look like?
Look for an online application with electronic signature, decisioning within an instant-to-24-hour window, and the option for a co-branded application form embedded on your own site.
Can clients keep their current gateway (Bambora, NMI, CyberSource, Authorize.Net, and similar) and still get these benefits?
With the right processor relationship, yes — most open gateways already have a direct integration path to a given processor, so your existing gateway setup often doesn’t need to change.
How many merchant accounts does a client need for card-present, card-not-present, and ecommerce combined?
A single MID (merchant ID) solution means one application and one account handling all processing environments, rather than separate accounts per channel.
Is a separate gateway ID needed for each currency supported?
Not necessarily — some providers offer multi-currency conversion through a single gateway account, letting clients sell in many currencies and receive funding in their own.
What fraud prevention and chargeback management options exist?
Look for add-on tools for chargeback prevention plus integrated fraud rules and technology available directly at the gateway level.
Are revenue share and partner portal options available?
Many processors offer referral fees calculated as a share of net income from boarded merchants, along with a partner portal for tracking referral data and residuals.
From completing an integration to onboarding and ongoing support, Cartis Payments works alongside software partners and their clients on exactly these questions. If you’re evaluating a payments integration, use this list to compare any provider against your actual requirements — not just the pitch.
FAQ
What is a payments sandbox account?
A sandbox account is a demo environment that lets developers code, build, and test a payment integration with test API credentials before deploying it to a live production environment.
Do I need a separate merchant account for card-present and card-not-present transactions?
Not necessarily. A single MID (merchant ID) solution can support card-present, card-not-present, and ecommerce processing under one application and account.
Can I integrate payments without switching away from my current gateway?
Often yes. Many processors can connect to your existing gateway relationship through established integration paths, so your software’s current gateway integration doesn’t need to change even as the underlying processing relationship does.
