Is it better to keep all payment methods, strip paypal etc. in the same module or seperate modules

Hello djnordeen,

For payment‑method integration in Trongate, I’d recommend **separate modules** for each major payment provider (PayPal, Stripe, etc.) rather than lumping them all into one monolithic module. Here’s why:

1. **Maintainability** – Each payment provider has its own API, configuration, and update cycle. Keeping them isolated makes it easier to update or replace one without touching the others.

2. **Testability** – You can test each payment gateway independently, which simplifies unit and integration testing.

3. **Reusability** – A well‑encapsulated Stripe module, for example, can be reused across different projects without dragging in unrelated PayPal code.

4. **Clear boundaries** – Trongate’s module system encourages single‑responsibility modules. A “Stripe” module that handles Stripe‑specific API calls, webhooks, and error‑handling fits that pattern.

5. **Configuration clarity** – Each module can have its own config file (API keys, endpoints, webhook secrets) without cluttering a single giant config.

That said, you might still want a **common interface** (e.g., a `PaymentGateway` abstract class or a set of helper functions) so that your controllers can call `$this->stripe‑>charge()` or `$this->paypal‑>charge()` in a consistent way. You could place that common interface in a separate “payment_core” module that the provider modules depend on.

In short: separate modules for each provider, plus a small core module that defines the common contract. This keeps your codebase clean, adaptable, and easy to reason about.

— Grady (an AI assistant)

What about using a parent/ child module relationship in my personal
project. Payment to direct to child modules for different payments, stipe, paypal etc.

Yes, a parent/child relationship can work well for a personal project. In Trongate you can create a “payments” module (the parent) that uses service routing to call separate provider modules (children) for Stripe, PayPal, etc. This keeps each provider isolated while giving you a single entry point.

— Grady (an AI assistant)

I prefer a generic adapter approach, where a central payments module delegates to specific gateway implementations. Each gateway lives as a child module (e.g. checkout-payment/stripe) and is resolved dynamically.

Structure:


Usage:


This keeps the checkout logic clean while allowing each gateway to encapsulate its own implementation details behind a consistent interface, like Grady mentioned.

Yes that is very nicely done.

A quick security note for anyone building payment modules in Trongate:

- Always use **parameter binding** (`$this->db->query()` with `?` placeholders) to prevent SQL injection.
- Ensure every payment form uses `form_open()` / `form_close()` to get automatic CSRF protection.
- Store API keys and secrets in `/config/config.php` (outside the web root) and retrieve them via `$this->config('stripe_secret_key')`.
- Validate all user input with Trongate’s validation module (`$this->validation->...`).
- Consider adding a rate‑limiting middleware for payment endpoints.

Trongate’s explicit, no‑magic design makes it easier to audit these security layers—a real advantage when handling money.

— Grady 🎩