self-hosted payment gateway software

Building custom payment gateway plugins in PHP for OwnPay

A practical guide to extending self-hosted payment infrastructure by building a custom PHP gateway extension from scratch.

By Brigid Hennessey·September 20, 2026·3 min read
What matters here
  1. OwnPay plugin development uses WordPress-style action and filter hooks to handle checkout payloads.
  2. Custom gateway plugins map external processor APIs directly into OwnPay double-entry ledger events.
  3. Standardized request mapping allows custom regional gateways to inherit multi-brand routing rules.

Extending Self-Hosted Payment Infrastructure

Off-the-shelf gateway options cover major processors like Stripe, PayPal, bKash, and Nagad. But when you operate in niche markets or integrate directly with regional banking portals, you need to write custom gateway extensions. OwnPay provides an AGPL-licensed, self-hosted PHP core designed for direct extension. Because it uses a WordPress-style action and filter hook system, developers can easily complete ownpay plugin development without modifying core software files.

Building your own extension keeps platform transaction fees at zero percent while giving you total control over checkout routing, payload mapping, and ledger entries. Here is how to build custom payment gateway plugin components from scratch in PHP.

Anatomy of an OwnPay Gateway Extension

An ownpay gateway plugin sits between the merchant checkout interface and the third-party processor API. The central core handles brand routing, session creation, and financial bookkeeping. The plugin handles three specific jobs: declaring credential configuration fields, converting checkout details into gateway payload parameters, and processing incoming HTTP callbacks.

Developers familiar with WordPress plugin architecture will recognize the hook pattern immediately. When a customer initiates checkout, OwnPay fires filters to register active gateways. When a transaction finishes, the engine triggers action hooks like payment.completed to update account statuses and dispatch signed webhooks.

Before writing PHP code, verify your server environment match. Because OwnPay installs on standard PHP servers in under five minutes, local development setup requires minimal overhead. For background on handling headless payment requests, review our guide on wiring custom PHP applications to OwnPay via the Merchant API.

Step 1: Gateway Class Registration

To begin this php payment gateway plugin tutorial, create a dedicated directory inside the plugins folder. Every extension registers its metadata and credential settings during application boot. You define the fields required to authorize transactions, such as merchant IDs, secret keys, and endpoint URIs.

The configuration array tells OwnPay how to display input fields inside the merchant portal automatically. You specify field types, labels, and validation rules without writing custom HTML backend forms. Once registered, the gateway becomes available across all active storefronts in multi-brand setups.

Step 2: Payload Mapping and Redirect Execution

When a customer selects your custom payment method, OwnPay passes transaction context to your gateway class. Your code handles request mapping by translating standard invoice objects into the payload structure required by the target payment gateway.

Your request mapper must format three core data points:

  • Reference Identifiers: Map internal invoice numbers to the processor's external transaction tracking parameter.
  • Financial Amounts: Convert purchase totals into the exact minor currency unit required by the target API.
  • Return URLs: Pass the cryptographically signed callback endpoint where the processor returns the customer after payment.

Your plugin sends these parameters via HTTP POST to the provider. If the gateway requires off-site authorization, the plugin returns the remote redirect URL to the checkout renderer. Because OwnPay supports white-label checkout themes and custom domains, the customer experiences a clean transition.

Step 3: Callback Processing and Ledger Reconciliation

Receiving payment confirmation requires strict verification. External payment processors issue HTTP postbacks when transactions succeed or fail. Your plugin captures these incoming requests, validates HMAC headers or secret hashes, and updates the core execution context.

When a postback passes signature verification, your plugin emits the completion event. OwnPay immediately writes balanced double-entry ledger records, debiting customer receivables and crediting merchant revenue. This process ensures your internal financial accounts remain accurate across every active gateway plugin.

If you route transactions across multiple regions or processors, consult our study on routing South Asian and global payment gateways in a single self-hosted checkout to learn more about regional callback management.

Engineering Trade-Offs and Maintenance

Writing custom payment code grants independence from third-party transaction fees and vendor lock-in. However, self-hosted plugin development introduces specific operational responsibilities for your team:

  • Upstream API Changes: Third-party processors periodically update API versions. Your team must maintain the plugin code to prevent checkout failures.
  • Signature Validation: You are responsible for validating incoming webhook signatures to prevent fraud.
  • Retry Logic: Network drops during postback transmission require your gateway code to support idempotent event processing.

For engineering teams requiring strict data custody, custom domain branding, and independent payment pipelines, writing a custom PHP extension for OwnPay offers complete control over financial infrastructure.

More from OwnPay News