Payment Security and Compliance: A Complete Framework for ISVs
For independent software vendors handling payments, security is not a checkbox. It is the architecture you inherit the moment you start processing transactions through your software. It shapes your merchant relationships, your liability profile, and your operating complexity for years. Most ISVs evaluating a payment platform underestimate this. They focus on the headline capabilities. They look at the API. They negotiate on fees. Security and compliance get treated as a vendor problem. It is not a vendor problem. It is your problem, with the vendor’s architecture as the starting point. This is a framework for thinking about payment security and compliance the way ISVs actually need to. It covers what to look for in a payment provider, what you remain responsible for, and where the real risk sits when you embed payments into your software. Why payment security is different for ISVs When you embed payments into a vertical software platform, you are not just a payments user. You are part of the payment infrastructure your merchants depend on. The security model becomes a stack. The payment provider handles transaction-level security: encryption, tokenization, fraud detection, PCI scope. You inherit the security posture of how you integrate that provider into your platform: where card data touches your systems, how you authenticate API calls, how you store sensitive tokens, how you handle merchant verification. Your merchants depend on both layers working together. A breach in either one damages their business and yours. This stacked responsibility is the structural reason ISVs need a different evaluation framework than the one a single-merchant SaaS company would use. You are evaluating security architecture for an entire downstream merchant base, not just for your own operations. The seven layers of a payment security framework A complete payment security framework for ISVs covers seven layers. Each addresses a specific threat surface. Each is a structural choice that compounds over time. 1. Encryption Every payment platform encrypts data. The question is where and how. End-to-end encryption (E2EE) means card data is encrypted at the point of capture and stays encrypted until it reaches the payment processor. The card data never lands unencrypted on your servers. This is the architectural decision that most meaningfully reduces your PCI scope. Transport Layer Security (TLS 1.2 or higher) protects data in transit between your systems and the payment platform. This is standard, but the version matters. TLS 1.0 and 1.1 are deprecated and should not appear anywhere in your payment stack. Encryption at rest covers tokens, customer records, and any payment-adjacent data your platform stores. AES-256 is the standard. 2. Tokenization Tokenization replaces sensitive card data with a non-sensitive token your system can store and reference without holding actual card information. There are two main types: provider tokens and network tokens. Provider tokens are issued by your payment platform and work within that platform’s ecosystem. They are useful for recurring charges, refunds, and account updater flows. Network tokens are issued by the card networks (Visa, Mastercard) directly. They survive across processors, automatically update when cards are reissued, and lower interchange because the networks treat them as lower risk than primary account numbers. Network token adoption is becoming the new baseline for any payment platform serious about both security and acceptance rates. 3. Authentication Authentication covers two distinct surfaces: how you authenticate API calls to the payment platform, and how the cardholder is authenticated during a transaction. API authentication: API keys, OAuth, and signed requests. Multi-tenant API key architecture matters here. If your platform serves hundreds of merchants, your authentication model needs to scope access cleanly so a breach of one merchant’s credentials cannot cascade. Cardholder authentication: 3D Secure (3DS) and the newer 3DS2. These are challenge protocols that verify the cardholder during a transaction. The major impact is the liability shift. When 3DS authentication succeeds, the liability for fraudulent chargebacks moves from the merchant to the card issuer. For ISVs whose merchants face high card-not-present fraud exposure (subscription billing, ecommerce, telehealth, fitness memberships), 3DS is not optional. It is the structural defense. 4. Fraud detection Fraud detection is moving from rule-based systems to AI-driven risk models. The shift is not cosmetic. Rule-based systems catch patterns someone has already coded into the rules. They are good at known fraud. They miss anything that does not match the rule structure. AI risk models identify pattern anomalies in real time. They catch fraud the rule engine would have approved. They learn from your transaction history, your merchant base, and the broader network of activity across the platform. The CSIPay Fraud and Risk Model flags transactions a rule-based engine would approve, and it does so without adding latency to the approval flow. For ISVs, the practical impact shows up in two places. Fewer chargebacks, because more fraud is caught before authorization reaches the issuer. Fewer false positives, because the model is better at distinguishing legitimate merchants from synthetic fraud patterns. 5. Access controls Access controls cover who inside your organization and your merchants’ organizations can see, change, or extract payment data. Role-based access control (RBAC) lets you define what different user types can do. A finance team member needs access to settlement reports. A support agent might need to see transaction status but not card details. A developer might need API access in a sandbox but not production. RBAC is how you make those distinctions structural rather than informal. Defining roles answers what someone can do. Authentication answers whether the person logging in is actually who they claim to be. That is where multi-factor authentication comes in. Multi-factor authentication (MFA) combines something the user knows (a password) with something they have (a one-time code or hardware key) or something they are (a biometric). Requiring both means a stolen password alone is not enough to get into the payment dashboard. Single-factor authentication is the structural risk that MFA exists to remove, and it is the reason MFA is non-negotiable for any admin-level access to the payment stack. The remaining controls sit underneath authentication. Session management defines how
Surcharging, Demystified: What the New CSIPay Surcharge Program Means for Partners and Merchants
Processing fees keep climbing. Merchants notice. Partners hear about it. For ISVs and vertical SaaS platforms, this conversation has become routine. A merchant calls. Their margins are tighter than last quarter. Credit card fees are part of why. They want to know if there is anything you can do about it. Until recently, the honest answer was usually no. Pass-through fees are pass-through fees. Negotiating them down has limits. Absorbing them yourself means giving up margin you cannot afford to lose. There is another option, and it has been quietly maturing for years. Surcharging. What surcharging actually is A surcharge is a small fee added to a credit card transaction that allows the merchant to recover the cost of accepting that card. The customer who chooses to pay by credit card pays the cost of that choice. The customer who pays by debit, cash, or another method does not. This is different from cash discounting, which works in the opposite direction. Cash discounting offers a reduced price to customers who pay by methods other than credit card. Both achieve a similar economic outcome. They differ in legal treatment, signage requirements, and how the fee or discount appears on a receipt. Surcharging used to sit on the edge of the payments industry. Today it is mainstream. Most U.S. states permit it. Card networks have published clear rules. Compliance tooling has matured. For high-volume merchants, it has become one of the most effective ways to protect margin without raising prices on the underlying product or service. The rules nobody can skip Surcharging is regulated. The rules are not optional, and partners who skip them put their merchants at risk of fines, processor termination, and reputational damage. The core rules: Surcharges apply to credit cards only. Debit and prepaid cards cannot be surcharged, regardless of how the customer runs the transaction. The surcharge cannot exceed 3 percent, or the merchant’s actual cost of acceptance, whichever is lower. Merchants must register their intent to surcharge with Mastercard before going live. Compliant signage must be displayed at the point of entry and the point of sale. The surcharge must be disclosed clearly on the receipt as a separate line item. At Constellation Payments, surcharging requires flat-rate pricing. Cost Plus pricing is not currently supported. These rules exist because the card networks want surcharging to be transparent. The customer should always know, before they pay, that a fee will apply if they choose credit. How the CSIPay Surcharge Program works The CSIPay Surcharge Program was built to make compliance straightforward. Two things matter most: it is automated, and it is compliant by default. Two integration paths are available depending on the partner’s setup. The first path is a direct API integration. Partners who are PCI compliant and already storing card data can call the BIN lookup endpoint, confirm the card is credit, and append the surcharge amount to the transaction using the feeAmount field. The total amount is calculated automatically and reflected in reconciliation reports. The second path is PayPageV3, the CSIPay hosted payment page. Partners who are not PCI compliant, or who simply want to avoid handling card data, can use PayPageV3’s dynamic surcharging option. BIN lookup happens natively. The surcharge is applied automatically when the payment method is returned as credit. No card data ever passes through the partner’s servers. Both paths share the same backend logic. Built-in BIN validation prevents debit and prepaid cards from being surcharged at the system level. Reconciliation is handled monthly. Reporting is transparent and shows the surcharge amount on every receipt and every statement. For partners, this removes the most common compliance failure points. A merchant cannot accidentally surcharge a debit card. The system will not allow it. What partners get out of it The surcharge program is positioned as a merchant solution, but it is also a partner opportunity. Retention. When a merchant raises processing fees as a concern, partners now have a real answer. That conversation builds trust. It positions the partner as a strategic advisor rather than a passive vendor. Revenue. The program supports revenue-sharing structures that allow partners to participate in the economics of the program directly. New line of business, with no new product to build. Differentiation. In a crowded vertical SaaS market, offering a fully compliant surcharge solution is a meaningful capability. Most platforms do not have one. The ones that do tend to win the merchants who care most about margin. Enablement. The CSIPay Surcharge Program ships with a full library of supporting materials. A Surcharge Addendum. An Attestation Form. Partner positioning and value proposition guides. Signage templates. An integration guide. Partners do not need to become surcharge experts to sell the program. The materials handle most of the work. Getting started For partners ready to bring surcharging to their merchants, the path is short: Review the Integration Guide to choose the right path (API or PayPageV3). Review the Partner Enablement Guide for the merchant onboarding process. Confirm the merchant is on flat-rate pricing. Have the merchant sign the Surcharge Addendum and Attestation Form. Guide the merchant through Mastercard registration. Display the required signage at point of entry and point of sale. Most partners can have a merchant live on the program within a week. For questions, the CSIPay implementation team is available at [email protected]. The processing rate is the line item every merchant sees. It is not the only cost they pay, and for the right merchant, it does not have to be a cost they absorb. The CSIPay Surcharge Program gives partners a clean, compliant way to put that decision back in the merchant’s hands.
CSIPay: The Payment Gateway That’s Finally on Your Side
As software platforms evolve into systems of record, customers no longer expect to be redirected elsewhere to complete a transaction. They expect payments to happen seamlessly, inside the product they already trust. That shift changes the role of payments entirely. What was once external infrastructure is now a core part of the product experience. For many software companies, that transition introduces complexity, dependency, and missed opportunity. This is why Constellation Payments built CSIPay, an embedded payments platform designed specifically for Constellation Software companies. It gives operating companies a simpler, more controlled way to embed payments directly into their products. The Problem With Relying on Third-Party Processors For years, software companies have used external processors to enable payments. That approach works early on. It becomes limiting as platforms scale. Control over merchant relationships fragments. Visibility into pricing narrows. Payment workflows evolve outside the product, shaped by external providers instead of internal strategy. Inside the Constellation Software ecosystem, the problem compounds. Different providers often handle different functions: online payments, recurring billing, in-person transactions. Operating companies end up managing multiple integrations, reconciling across fragmented reporting, and absorbing overhead across engineering, support, and compliance. Payments stop being an enabler and start becoming a constraint. One Platform. One Integration. Full Control. CSIPay replaces that fragmentation with a single, unified infrastructure. Rather than requiring operating companies to build and maintain their own payment stack, CSIPay centralizes the core stages of modern payment processing. Merchant onboarding, authorization, fraud controls, compliance, capture, settlement, and reporting all live on one platform, with the full experience embedded directly within the product. Transactions originate inside the platform, whether through online checkout, recurring billing, or in-person environments. They are validated and routed through the appropriate payment networks or ACH rails. Funds settle directly to merchant accounts, with unified reporting across the lifecycle. Built to Earn Merchant Trust For merchants, payment reliability is not a feature. It is an expectation. A failed transaction does not just impact revenue. It impacts trust in the platform where the transaction occurred. CSIPay is built on that understanding: PCI DSS Level 1 Service Provider certification (v4.0.1), the highest security standard in the payments industry 99.9% uptime service level agreemen. End-to-end encryption, real-time fraud detection, and advanced tokenization These are not differentiators. They are the baseline required to operate at scale, and CSIPay meets that baseline without compromise. What It Means for Your Business Embedded payments are not just a technical capability. They are a strategic lever. Revenue stays internal. Payments shift from a pass-through cost to a revenue stream. Payment economics that would otherwise flow to an external processor remain inside the operating company, and that value scales directly with transaction volume. Time to market accelerates. Centralized infrastructure removes months of integration work, compliance setup, and processor negotiations. New payment programs launch faster and with lower risk. Customer relationships deepen. When payments are embedded into the product, the platform becomes more integral to the customer’s daily operations. That increases retention, raises switching costs, and improves lifetime value. Operational complexity decreases. A unified system replaces multiple processors and fragmented integrations. Engineering time that was spent managing infrastructure can be redirected back to building product. Competitive position strengthens. In vertical markets, seamless payment experiences are increasingly the expectation. Platforms that deliver them natively hold a meaningful advantage over those that do not. Why This Matters Now The shift toward embedded payments is already underway. Customers expect transactions to happen inside the platforms they use every day. As those expectations grow, reliance on external processors becomes a limitation rather than a convenience. At the same time, scale changes the economics of payments. What was once a cost center becomes a meaningful source of revenue and control. Purpose-Built for the Constellation Ecosystem CSIPay is designed specifically for Constellation Software companies and the vertical markets they serve. By centralizing infrastructure across the ecosystem, operating companies benefit from consistent compliance standards, shared operational support, and unified reporting without having to build those systems independently. The value generated through payments stays within the ecosystem, not with an external processor. For Constellation Software companies, this is where payments move from dependency to ownership. Ready When You Are CSIPay is live in the United States, supporting card and ACH processing across online, recurring, and select in-person programs. Card-not-present processing is live in Canada, with card-present and EFT support planned for future phases. International expansion and additional payment methods are on the roadmap. CSIPay is live. See what embedded payments can do for your platform.
What Is a Payment Gateway? Features, Benefits, and Modern Capabilities
