Payment gateway setup β
A payment gateway is what actually moves the money. GCM doesn't hold merchant accounts β instead, we connect to a gateway you (or the platform) already have, and we hand off card details to it for every charge.
This is the same engine that powers the online donation form, recurring donations, and your monthly subscription billing.

Platform default vs your own gateway β
When you create an organization, GCM defaults to the platform gateway β settlements land in the GCM holding account and we remit to your bank weekly. This is the fastest way to start taking donations, and most churches stay on it for the first month.
You switch to your own gateway when:
- You want settlements to land directly in the church's bank, no holding account in between.
- Your processor offers lower rates than the platform default.
- You operate in a country the platform default doesn't settle to.
- Your board has compliance reasons for owning the merchant relationship.
In Settings β Payment gateway, toggle Use your own gateway on. The credential fields appear below.
TIP
You can flip back to the platform default at any time. Existing recurring donations keep using whatever gateway recorded their token β but new ones use the active gateway.
Supported gateways β
| Gateway | Type | Recurring | Best for |
|---|---|---|---|
| PowerTranz (Direct) | API | yes | Caribbean / LATAM; recurring giving |
| PowerTranz (Hosted Page) | Redirect | no (one-time only) | minimum PCI scope |
| Genius Checkout | Redirect | yes (via tokens) | global coverage, hosted checkout |
PowerTranz is the most-used gateway in our user base because of strong Caribbean and Latin American coverage. Genius Checkout is the global option β it's a hosted page that settles in 52+ currencies.
PowerTranz (Direct) β
Direct means GCM collects card details and POSTs them to PowerTranz's API. The payer never leaves your domain. This is required if you want recurring giving β only the direct adapter supports tokenized card-on-file.
You'll need from your PowerTranz account manager:
- PowerTranz ID β your merchant ID, e.g.
88803195. - Password β the API password (write-only β we encrypt it at rest).
- Acquirer ID β sometimes required by your acquirer (e.g.
464748). - Environment β staging while you test, production when you go live.
- Capture mode β Sale (charge immediately) or Auth + Capture (hold the funds, capture later).

After saving, click Test connection. We hit a low-cost endpoint that confirms the credentials reach PowerTranz successfully. A green badge appears when verified.
PowerTranz (Hosted Page) β
The hosted-page (HPP) flavor of PowerTranz puts the card form on PowerTranz's domain, not yours. The payer enters card details there and we never see the PAN. This is the lowest PCI exposure option.
Same credentials as the direct adapter, plus:
- Hosted Page Set β the page set ID PowerTranz provisioned for you.
- Hosted Page Name β the page within the set.
Trade-off: the HPP adapter does not support recurring giving. PowerTranz can only tokenize a card during a browser session, and recurring charges happen on a schedule with no browser. If you want recurring with PowerTranz, use the direct adapter.
Genius Checkout β
Genius Checkout (GC) is our preferred option for churches without an existing processor relationship. It's a hosted payment page like PowerTranz HPP, but it also supports recurring charges via long-lived tokens.
You only need one credential:
- GC API key β starts with
gc_test_β¦orgc_live_β¦.
The integration handles everything else automatically: checkout sessions, success / failure redirects, signed webhook callbacks, subscription state changes. We map GCM's internal ISO 4217 numeric currency codes to GC's alphabetic codes β 52 currencies supported, including USD, EUR, GBP, JMD, KES, NGN, ZAR.

How card data is stored β
Once a card is tokenized, we store:
- A gateway token (PowerTranz's
SpiTokenor GC'stok_β¦). - The card brand (Visa, Mastercard, β¦).
- The last 4 digits.
- The expiry month + year.
The full PAN never lands in our database. For recurring donations and saved cards, GCM charges the token β the gateway resolves it back to the underlying card on their side.
Testing the flow β
Before going live, run a $1 donation through the donation form using a test card:
| Gateway | Approved card | Declined card |
|---|---|---|
| PowerTranz | 4111 1111 1111 1111 | 4000 0000 0000 0002 |
| Genius Checkout | 4242 4242 4242 4242 | 4000 0000 0000 9995 |
All gateways accept any future expiry and any 3-digit CVV in test mode.
Refunds and voids β
Both gateways support full and partial refunds from inside GCM. Open a donation in Giving β Donations, click the action menu, and pick Refund. The gateway processes the reversal, the donation row gets a refunded_amount, and a row is appended to payment_attempts for the audit trail.
Voids (zeroing out an authorization before capture) are only meaningful in Auth + Capture mode β they release the hold without ever charging the card.
Switching gateways later β
When you switch active gateways:
- One-time donations start using the new gateway immediately.
- Recurring donations continue charging on the old gateway until you migrate the cards β tokens are not portable between processors. For most churches the cleanest path is to email donors a "please update your card" link rather than try to migrate tokens.
Cross-references β
- Online donation form β where these gateways actually get used.
- Recurring donations β token lifecycle and renewal handling.
- Webhooks reference β gateway webhook signatures.
