GCM Docs

Appearance

Adding a payment method ​

To move from trial to paid (or to switch cards on an active subscription), you need a card on file. GCM uses hosted checkout for this — you type your card details on a payment-gateway page, not on GCM. We get back a token we can use for future charges.

Update card button

How the card-on-file flow works ​

GCM is a multi-tenant platform that uses a gateway-agnostic adapter pattern. The two adapters that ship today are:

  • PowerTranz — direct integration. Default for most churches.
  • Genius Checkout — redirect-based hosted payment page (HPP). Used in regions where PowerTranz isn't available or when your church's gateway account routes through Genius.

Both adapters do the same thing from your perspective: you click a button, you land on a secure card-entry page, you fill it in, you get redirected back to GCM with success or failure status.

The card number itself never touches GCM's servers — we receive a token (tok_xxx) plus the card brand and last 4 digits. The token is what we charge against next month and every month after.

Why this matters

Because we never store your full card number, your church is not in PCI scope for card storage. The gateway's HPP handles the PCI-DSS compliance; GCM handles only tokens.

Adding your first card ​

You'll be prompted for a card when you click any paid plan tile during your trial — or you can do it ahead of time:

  1. Go to Billing (settings menu or /billing).
  2. In the Choose a plan section, click the plan you want.
  3. You'll be redirected to the hosted checkout page (you'll see the gateway's URL in your browser bar — app.geniuscheckout.com for Genius, or PowerTranz's domain).
  4. Enter your card number, expiry, CVV, and billing ZIP.
  5. Click Pay. The gateway processes the card.
  6. On success, you're redirected back to GCM's billing page with a Payment successful! toast. Your subscription is now active.
  7. On failure, you're redirected back with an error toast. The card was never charged; nothing was saved. Try a different card or check the error message.

The first successful payment also stores the card token. Subsequent monthly renewals charge that stored token without redirecting you anywhere — they happen silently in the daily cron job.

Updating the card on file ​

When your card expires, or when you need to switch to a different card:

  1. Go to Billing.
  2. In the Current plan card, find the card display (it shows brand + last 4 + expiry).
  3. Click Update card.
  4. You're redirected to the hosted checkout for a card-update flow — same UX as a fresh payment, but no charge runs. The gateway returns a new token; we overwrite the old one.
  5. You're redirected back with a Card updated toast.

The next renewal will charge the new card.

WARNING

Updating the card does not retry a failed payment by itself. If your subscription is past_due, after updating the card you also need to click Pay now to actually charge the new card and bring the subscription current. See Invoices & failed payments.

What we store ​

These columns live on your organization record:

  • card_brand — Visa, Mastercard, Amex, Discover.
  • card_last4 — last 4 digits, for display only.
  • card_expiry — YYYYMM expiry, for the Expires MM/YY display.
  • stored_card_token — the gateway token. We never log or display this.

If you're paying with a non-card method (bank transfer for an Unlimited plan, for example), card_brand is empty and the card display is replaced by a payment-method note.

Multiple gateways and routing ​

GCM uses a gateway adapter registry — at runtime we look up which gateway your church's payment config points to and route the request to that adapter. As an admin you don't pick the gateway; it's configured at the platform level based on your country.

If your charges need to switch gateways (because you moved jurisdictions, or because we add a new adapter that suits you better), reach out and we'll migrate your token. The change is invisible to you — same monthly cadence, same card on file.

Failed card entry ​

If the card was declined at entry time, the most common reasons are:

  • CVV mismatch — re-type the 3-digit code on the back (or 4 on the front for Amex).
  • AVS mismatch — billing ZIP doesn't match what your bank has on file. Use the address your bank knows, not your church address if those differ.
  • Insufficient funds or bank blocked — call your card issuer.
  • Sanctioned country — some card schemes block transactions originating from certain regions. Try a different card.

The error message comes from the gateway; we surface it verbatim plus the error code. If you need help interpreting an error code, screenshot the toast and email support — the code maps to a known reason on the gateway side.

Security ​

  • All card entry happens on the gateway's domain over TLS 1.2+.
  • GCM never logs the PAN, CVV, or token in plain text. Tokens are encrypted at rest with PAYMENT_ENCRYPTION_KEY.
  • The hosted checkout pages are PCI-DSS Level 1 certified.
  • Card brand + last 4 + expiry are display-only; they're shown to admins and treasurers but no one else.

TIP

GCM's PCI boundary is enforced by an automated check — scripts/check-pci-boundaries.sh — that blocks any code change that would put the PAN inside our application boundary. If a refactor accidentally pulls card data into GCM, the CI build fails.

Next steps ​