Payment gateway overview

Updated Oct 17, 2026 Payments

TitanCart ships with eight payment gateways built into the plugin itself. There are no payment gateway extensions — everything below is core. You can run as many as you like at the same time, and the customer picks one at checkout.

The eight gateways

These are the exact names you will see in the Gateway type list when you add a payment method.

Credit / Debit Card (Stripe) — card payments through Stripe, using an inline card form on your own checkout page. See Stripe setup.
PayPal — the PayPal buttons and approval flow. See PayPal setup.
Venmo — its own gateway row, powered by the same PayPal app credentials. Venmo is a funding source of PayPal, so money lands in the same PayPal account, but orders, transactions, refunds and reports all read Venmo. Available to US shoppers paying in USD; the button hides itself for everyone else.
Credit / Debit Card (Square) — card payments through Square, popular with merchants already using Square in a physical shop. See Square setup.
Credit / Debit Card (Authorize.net) — long-established US gateway, often paired with a merchant account from a traditional bank. See Authorize.net setup.
Cash on Delivery — the customer pays when the order arrives.
Bank / Wire Transfer — you publish your account details and the customer transfers the money.
Pay by Check — you publish a payee name and mailing address and the customer posts a cheque.

The last three are the offline methods: no gateway fees, no API, and you confirm payment by hand. See Offline payment methods.

There are no payment gateway extensions. If you are looking for Mollie, Braintree, Razorpay, Klarna or similar, TitanCart does not offer them and the Extensions Marketplace does not sell them. TitanCart does expose a developer hook (titancart_register_gateways) that a custom plugin can use to add its own gateway, so a bespoke integration is possible — but nothing ready-made exists today.

What TitanCart Lite includes

The gateway list differs by edition.

TitanCart Lite — Stripe, Cash on Delivery, Bank / Wire Transfer and Pay by Check. That is a complete, working card checkout at no cost.
TitanCart Pro — adds PayPal, Venmo, Square and Authorize.net.

The split is enforced in two places, which is worth knowing if you ever move between editions: a Lite store cannot create or edit a Pro gateway, and Pro gateways are filtered out of the checkout list on a non-Pro store. So if a Pro subscription lapses, a PayPal method you had configured stops appearing at checkout even though the row is still sitting in your admin. Renewing brings it straight back — nothing is deleted.

Where to set them up

Go to Settings → Payment Gateways. The list shows one row per payment method you have created, with these columns:

Pos — the sort order used at checkout. Lower numbers appear first.
Gateway — the name you gave it, with the underlying gateway type beneath.
Surcharge — a fee you add for using this method, or an em dash if there is none.
Status — Active or Disabled.
Actions — Disable / Enable, and Delete.

Click anywhere on a row to open it. The button at the top right is + Add Payment Gateway.

A brand-new store is not empty. TitanCart seeds exactly one method on first run — Cash on Delivery, active, with its post-checkout status set to On Hold. Everything else you add yourself.

Disable and Delete are not the same thing. Disabling stops the method appearing at checkout and keeps its credentials. Deleting removes the row and its saved credentials permanently. Past orders are unaffected either way — the payment method name is copied onto each order when it is placed, and payment transaction records are kept.

Adding a gateway

Click + Add Payment Gateway. The editor opens on the General tab:

Gateway type — pick the underlying processor. This cannot be changed after you save. If you pick the wrong one, delete the row and start again.
Name (required) — what the customer sees at checkout, e.g. Credit / Debit Card. The Save button stays disabled until you fill this in.
Description — a short line shown under the name on the checkout radio.
Payment instructions — shown after checkout, not during it: at the top of the Payment Instructions card on the thank-you page and the customer’s order page, and in the order confirmation e-mail (TitanCart 0.2.47 or later). Bank Transfer and Check add their account details or mailing address from their own Configure tab underneath.
Status — Active or Disabled.
Position — the checkout sort order.
Surcharge — an extra fee, either Fixed ($) or Percent (%).

Save, and a second tab appears: Configure, holding the API credentials and per-gateway options. The Configure tab does not exist until the method has been saved once, which surprises people who expect to paste keys straight away.

At the bottom of Configure is ⚡ Test Connection. It makes a small, harmless call to the provider — a balance read for Stripe, a token request for PayPal — and reports success or the exact error. Offline methods return success immediately, since there is nothing to reach. Use it before you go anywhere near a real order.

Test mode and going live

There is no single site-wide test switch. How you move between test and live depends on the gateway, and the two shapes are opposites.

Stripe has no sandbox toggle at all. The environment is decided purely by which keys you paste: pk_test_ / sk_test_ are test, pk_live_ / sk_live_ are live. Swapping the keys is the whole of going live.
PayPal, Venmo, Square and Authorize.net each have their own Sandbox Mode checkbox on the Configure tab, and all four ship with it switched on. Pasting live credentials without unticking it sends those credentials to the sandbox endpoint, and every transaction fails.

The most common go-live mistake. Live keys plus Sandbox Mode still enabled. The gateway rejects everything and the error rarely says why. Untick Sandbox Mode, save, then run Test Connection — it talks to whichever environment the settings currently point at, so a green result confirms the environment as well as the credentials.

For the full test-then-launch sequence across every gateway, see Going live with payments. For finding your test payments on Square’s side, see Finding your Square sandbox transactions.

Webhooks — Stripe only

Stripe is the only gateway in TitanCart that uses a webhook. When you open a Stripe method, the General tab shows the URL to paste into your Stripe dashboard, under Developers → Webhooks. No other gateway has one, and no URL is offered for them, because none exists to receive it.

The other gateways do not need one. PayPal, Venmo, Square and Authorize.net all settle synchronously: the charge is captured and verified server-side during checkout, before the customer reaches the thank-you page. There is no later message to wait for.

What the Stripe webhook actually handles is a short list: a payment intent succeeding, a payment intent failing, and a saved-card setup succeeding. Refund events are received but ignored, because refunds are already reconciled when you issue them from Sales. Disputes and chargebacks are not handled — watch for those in your Stripe dashboard, not in TitanCart.

The Stripe webhook is fail-closed. If the Webhook Signing Secret field is empty, the endpoint rejects every incoming event with a 401 rather than trusting it. That is deliberate — without the secret, anyone could post a fake “payment succeeded” event. It also means a Stripe method with no signing secret shows a red NEEDS SETUP badge in the gateway list. Card payments still work in that state, because checkout verifies the payment directly with Stripe; it is the follow-up events that are being turned away.

Orders do not get stranded in Pending Payment just because a webhook is missing. Every gateway re-reads the payment from the provider before the order is committed, so the status you see is the status the provider confirmed.

Surcharges

Each payment method can carry a surcharge — a fixed amount or a percentage — added to orders that use it. Two details matter:

A percentage surcharge is a percentage of the cart subtotal, not of the order total. Shipping, tax and tips are excluded from the calculation.
The surcharge is not itself taxed. It is added after tax has been worked out.

The customer does not see the surcharge before they order. The checkout radio shows only the method name and description, and nothing recalculates the order summary when the shopper picks a different payment method. The surcharge is applied server-side when the order is placed, and first appears on the confirmation page and the invoice as Payment surcharge. If you charge one, say so in the method’s Description so nobody is surprised — and check your local rules, because several US states regulate how card surcharges must be disclosed.

Which gateways work with subscriptions

If you sell subscriptions, only the gateways that can store a reusable payment token can take a renewal: Stripe, PayPal, Square and Authorize.net. Venmo cannot — Venmo funding never vaults a token, so there is nothing to charge on renewal day. Cash on Delivery, bank transfer and cheque are excluded for the same reason.

You do not have to police this yourself. When a subscription product is in the cart, checkout hides the methods that cannot renew and shows an amber notice explaining which ones were withheld and why. See Subscriptions setup.

Card security

Card numbers are never posted to your server and are never stored in your database. Each card gateway loads the provider’s own script into the checkout page — Stripe Elements, Square’s Web Payments SDK, Authorize.net’s Accept.js — and the card details go straight from the shopper’s browser to the provider, which returns a token. TitanCart only ever handles that token. PayPal and Venmo go further still: the shopper authorises inside PayPal’s or Venmo’s own window.

TitanCart takes no cut of any transaction. You pay your provider’s published rates directly.

On PCI compliance, talk to your acquirer. Which self-assessment questionnaire applies to your store is decided by your acquiring bank and processor, not by us, and it depends on how the payment form is integrated. TitanCart’s card forms are embedded fields on your own checkout page rather than a redirect to a provider-hosted page, and that distinction is exactly what the questionnaire rules turn on — under current PCI DSS guidance an embedded form carries obligations around the scripts running on that page that a full redirect does not. Do not assume a particular questionnaire level from this article; ask your provider which one they expect of you and what they will confirm on your behalf.

Settings that do not do anything yet

A few fields on the Configure tab are not wired to anything. They are listed here so you do not spend time on them or assume a behaviour you are not getting. Each one is on our list to either finish or remove.

Stripe → Payment Type — offers Stripe Checkout (redirect to Stripe-hosted page) and Card Elements (inline card form on your site), and it is ignored. TitanCart always uses the inline card form. Note that the redirect option is also the field’s default, so the setting shows a mode the store has never had. If you specifically need Stripe’s hosted page, TitanCart cannot do that today.
Stripe → Currency and Account Country — ignored. Charges are made in the order’s own currency, which comes from your store currency settings.
PayPal → Currency — ignored, for the same reason.
Authorize.net → Accepted Card Types — the hint says the list is displayed to customers at checkout. It is not displayed anywhere, and it does not restrict which cards are accepted. Which brands you can take is set in your Authorize.net account.

Limits worth knowing

Run one method per card gateway. Nothing stops you creating two Stripe methods, but the checkout card form and the webhook secret are both resolved by looking up a single Stripe row, so a second one can leave the card fields missing or the wrong signing secret in use. Use one row per gateway type and control visibility with Status.
The NEEDS SETUP badge only checks Stripe. It fires for one thing: an active Stripe method with no webhook signing secret. An active PayPal method with no Client ID, or a Square method with no access token, will show no badge at all. Do not read a clean list as proof that every gateway is configured — use Test Connection on each one.
Bank transfer and cheque orders stay in Pending Payment. They are not moved to a separate awaiting-payment status, and no status-change note is written. Move them on by hand from Sales once the money arrives. Cash on Delivery is the exception: it has its own Order Status After Checkout setting, defaulting to On Hold, with Processing as the alternative.
Refunds are issued from the order, not from this page. See Managing orders.

Troubleshooting

No payment options at checkout. Every method is Disabled, or they are all Pro gateways on a store that is not on Pro. Check Status in the gateway list first.
Every transaction fails with live credentials. Sandbox Mode is still ticked on the Configure tab. Stripe stores should check the key prefix instead.
The card fields never appear when Stripe is selected. The Publishable Key is empty, or you have more than one Stripe method and the first one is the incomplete one.
A red NEEDS SETUP badge on Stripe. The Webhook Signing Secret is missing. Payments still work; add the secret so Stripe’s follow-up events are accepted.
The Venmo button does not show. Venmo is offered only to US shoppers paying in USD. The button removes itself for everyone else, by design.
A gateway disappeared from checkout after a renewal lapse. PayPal, Venmo, Square and Authorize.net are Pro-only and are filtered out of checkout on a non-Pro store. The configuration is intact and returns when Pro is active again.
The customer was charged more than the total they saw. A surcharge is configured on that method. Surcharges are applied at order time and are not shown on the checkout radio.