piprapay/piprapay

1. Purpose and runtime

PipraPay is a self-hosted PHP payment-automation platform. It unifies API-backed, manual, and SMS-verified payment methods through pluggable gateway modules, with customer-facing checkout/payment pages and an administrative control plane. It is deployed behind an Apache-compatible web server (.htaccess) and initialized against a SQL schema.

Paths: index.php, .htaccess, pp-content/pp-install/db.sql

2. Application bootstrap and shared core

The public request entry point is index.php; installation has a separate entry point. Shared adapter and function layers under pp-include are the likely core boundary between page controllers, persistence, and modules. Maintenance and requirement scripts support operational gating and environment checks.

Paths: index.php, pp-content/pp-include/pp-adapter.php, pp-content/pp-install/index.php

3. Public payment workflow and themes

A theme module owns public checkout, gateway selection, payment-link, invoice, and checkout-status views. This separates branded/public payment presentation from payment orchestration. A payment link or invoice routes a payer into the active theme, which presents enabled gateways and then reports payment status.

Paths: pp-content/pp-modules/pp-themes/twenty-six/checkout.php, pp-content/pp-modules/pp-themes/twenty-six/gateway.php, pp-content/pp-modules/pp-themes/twenty-six/checkout-status.php

4. Gateway plugin boundary

Each payment connector is isolated in a gateway directory with a class.php implementation and gateway-specific assets. The core/admin configuration selects and configures gateways; the public flow delegates provider interactions to the matching module. Modules include direct APIs (Stripe, PayPal, SSLCommerz, aamarPay), crypto providers, and manual/mobile-wallet verification variants.

Paths: pp-content/pp-modules/pp-gateways/stripe/class.php, pp-content/pp-modules/pp-gateways/bkash-api-tokenized/class.php, pp-content/pp-modules/pp-gateways/nowpayments/class.php

5. Administrative control plane

The PHP admin area provides authentication including 2FA/recovery, then routes privileged users to dashboard and domain management screens. It manages brands, customers, gateway definitions, payment links, invoices, transactions, staff permissions, and reporting. This is the principal configuration and operational boundary for the payment system.

Paths: pp-content/pp-admin/login.php, pp-content/pp-admin/2fa.php, pp-content/pp-admin/pp-root/dashboard.php

6. Verification, transaction, and device operations

Payment lifecycle management spans transaction records, balance verification, SMS data, and device management. This reflects the platform’s non-API payment automation model: companion-device/SMS inputs can support verification alongside gateway callbacks or manual flows. Cron-job settings imply scheduled reconciliation or background processing, though the scheduler runtime is externally provisioned.

Paths: pp-content/pp-admin/pp-root/transaction/index.php, pp-content/pp-admin/pp-root/devices/balance-verification.php, pp-content/pp-admin/pp-root/sms-data.php

7. Branding, integrations, and infrastructure

Multi-brand behavior is configured through brand and global settings, including themes, currencies, FAQs, and API settings. Domains are managed in the admin surface, suggesting branded/domain-specific payment endpoints. External dependencies include payment-provider APIs, an Android companion application for verification, and the FPDF and Google Authenticator libraries for invoice/document generation and 2FA.

Paths: pp-content/pp-admin/pp-root/brands/index.php, pp-content/pp-admin/pp-root/brand-setting/api-setting.php, pp-media/sdk/fpdf/fpdf.php