Payment Methods

Payment Methods

Payment methods are defined for the installation and then enabled per cart, so different shops can offer different ways of paying.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

Architect Panel → Configuration:

• Instance Configuration Fields — where gateway credentials live

Two kinds

• Online — taken through a gateway at checkout. Card, and the wallet methods that sit on top of it.
• Offline — recorded as a promise to pay, settled outside the shop. Cash, bank transfer, cash on delivery.

The distinction matters because an offline method means an order exists that has not been paid for. Somebody has to reconcile it, and if nobody does, you have shipped goods for free.

The list is per installation

Each method carries a name, whether it is enabled, whether it is offline, and the icons shown at checkout. Enabling a method for a cart is a separate step, so a method can exist without every shop offering it.

Only enable what you can honour

The common failure. A method appears at checkout because it was enabled during setup, a customer chooses it, and nobody has arranged to actually process it.

Before enabling one, be able to say who handles it and how it is reconciled.

Offline methods need a process

An order paid by bank transfer sits waiting for somebody to confirm the money arrived and mark it accordingly. Decide who does that and how often before you offer it — weekly is usually enough, never is not.

Credentials belong in instance configuration

Not in a field on the cart. Gateway keys are among the most sensitive values you hold, and instance configuration is where they are encrypted and restricted.

Fewer is usually better

Every method is one more thing to reconcile, support and explain. Most shops need card and perhaps one alternative; a checkout offering six methods is usually offering four nobody uses.

Test each one you enable

End to end, with a real order, before opening. A method that appears but fails is worse than one that is not offered, because the customer has already decided to buy.

Worked example

A shop offers card and bank transfer only. Bank transfer orders are held until the finance team confirms receipt, which they do each morning from a saved view of unpaid orders — a five-minute job that replaced an untracked spreadsheet.

Recommendations

• Enable only what you can process.
• Name who reconciles each offline method.
• Keep credentials in instance configuration.
• Place a real order through every enabled method.

Forcing a Single Method

A cart can be restricted to a single payment method, so checkout offers no choice.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

When it is right

• A trade shop where everything is invoiced, and offering a card would confuse the account.
• An internal shop settled by payroll deduction or a cost code.
• A collection-only shop paid for on arrival.
• During setup, where only one method has actually been tested.

What it costs

Choice at checkout is worth something. A customer who cannot pay the way they expected abandons the basket, and you do not find out why.

So restrict deliberately, for one of the reasons above, rather than because it simplifies configuration.

Say so before checkout

The frustrating version is a customer filling a basket, entering addresses, and only then discovering the shop does not take cards. If there is one method, say so on the shop rather than revealing it at the last step.

It is per cart

Which is the point. An installation can run a card-only public shop and an invoice-only trade shop side by side, each restricted appropriately, without either affecting the other.

Revisit it

A restriction added during setup, because only one method was ready, tends to survive long after the others were tested. Check what your carts actually offer against what you meant them to offer.

An offline-only shop still needs reconciliation

Arguably more, because every order is unpaid until somebody confirms it. Restricting to bank transfer does not reduce the work; it concentrates it.

Worked example

A trade shop is restricted to invoice, stated on the shop's front page, with orders released once the account is checked. The public shop on the same installation takes cards only. Neither restriction affects the other, and neither surprises a customer at checkout.

Recommendations

• Restrict for a reason, not for convenience.
• Say so up front, not at checkout.
• Review restrictions left over from setup.
• Plan reconciliation for an offline-only shop.