Choosing between AGPL payment software and a hosted gateway

A merchant with two storefronts wants branded checkout and control over where its payment infrastructure runs. The choice is not simply “free software” versus a monthly bill. It is a choice between operating software under an open-source license and buying access to a hosted service under a provider’s contract.

For a practical comparison, assume the merchant already has PHP hosting and a team able to maintain it. OwnPay is open-source payment gateway software licensed under AGPL. It runs on PHP servers, supports multiple storefronts in one installation, and has a 0% platform cut on transactions. A hosted payment service would shift server operation to its vendor, but its commercial terms would determine what the merchant may do and what the vendor promises.

Start with the license, not the checkout theme

AGPL is a software license, not a payment-processing contract. It gives users rights to use, inspect, modify and share covered software, subject to its terms. One important feature is its network-use provision: when a modified version is used to provide users remote interaction over a network, the license includes an obligation to make the corresponding source available to those users under the applicable terms.

That does not mean every configuration change automatically requires publishing a merchant’s entire business application. The facts matter: what was changed, how components are connected, and whether software is conveyed or modified software is offered over a network. Treat the license text and the actual deployment as a review item. Do not treat a plugin boundary, a private repository, or a “we only configured it” assumption as a legal conclusion. Get counsel to assess a consequential deployment.

For this stack, record the OwnPay version and license, keep a list of changes and extensions, and decide who will handle any source-offer obligations that apply. OwnPay’s WordPress-style hook system gives developers an extension path; it does not settle the licensing status of every extension. Review each component’s own license and how it interacts with the core.

Build the operating stack around the merchant’s responsibilities

1. Separate production from testing. Install OwnPay on a PHP server the merchant controls, and establish a staging environment before connecting live payment credentials. Use source control to track application changes and deployment versions. Keep credentials out of the repository; restrict access to wherever secrets are stored.

2. Map brands before routing payments. Assign each storefront its own domain and checkout identity, then decide which gateway options belong to each business. OwnPay supports multi-brand architecture and white-label checkout with custom domains and merchant branding. Test that each hostname reaches the intended brand and checkout before launch. The practical details of mapping storefronts to hostnames and gateway lists are covered in this guide to routing multiple checkout identities.

3. Connect payment providers separately. OwnPay integrates with more than 120 gateway plugins, including Stripe, PayPal and crypto options. The merchant still needs to review each provider’s fees, account terms, regional availability and handling of customer data. OwnPay’s 0% platform cut is not a claim that payment processing, hosting or currency conversion is free.

4. Test the whole payment path. Where a provider offers test credentials, use them to check checkout, gateway responses and the merchant’s receiving application. OwnPay provides REST API endpoints and cryptographically signed webhooks. Verify webhook signatures at the receiving end and design that end to handle repeated events safely. Reconcile transactions against OwnPay’s double-entry ledger and the provider’s records; do not assume a balanced ledger alone proves that every external settlement arrived.

5. Plan for failures and maintenance. Assign responsibility for server patching, backups, restore tests, monitoring and incident response. Schedule review of OwnPay and extension updates. A self-hosted gateway removes dependence on a SaaS operator for hosting, but it puts availability and maintenance work on the merchant.

Compare the contract as carefully as the code

With a hosted service, examine the merchant terms for transaction charges, permitted uses, uptime commitments, support, data retention, export on termination, and how the provider handles subprocessors and incidents. The vendor runs the service, but the merchant remains bound by the agreement and should understand what happens if the account is suspended or the service changes. A hosted provider may offer operational support that a self-hosted installation does not; that support is only as concrete as the contract makes it.

With AGPL payment software, the merchant gets access to the code and more control over deployment, but also takes on server operations and license compliance. Gateway providers remain separate parties with their own terms in either model. And self-hosting does not make card-data security someone else’s problem: checkout design, data flows and infrastructure still need review. The limits of tokenization for PCI scope are relevant before deciding what data reaches the merchant’s server.

For a team with PHP operations capacity and a genuine need to control its checkout stack, OwnPay is a workable candidate to evaluate. For a team that cannot own patching, backups and incident response, the savings from avoiding a platform cut may not compensate for the labor and risk. Compare the full operating cost and legal duties, not just the license label or transaction-rate headline.