Store Checkout and Payment Options in Posty5

What a shopper actually goes through at a Posty5 checkout — destination, delivery fee, coupon, payment — and the honest answer about paying online.

ADAdvertisement
Store Checkout and Payment Options in Posty5

If you are evaluating Posty5 to sell something, one question decides most of it, so here it is first rather than five sections down. Shoppers pay cash on delivery. The payment framework around that is complete and genuinely provider-agnostic, but the catalogue of gateways contains cash on delivery and nothing else, and no provider adapter is connected. A store you build today takes orders and collects on delivery.

Can customers pay online? The short answer

It is worth understanding why that is the state rather than assuming it is an oversight. The framework has everything a real integration needs: payment sessions, signed webhooks with verified signatures, refunds, per-country method resolution, and separate merchant and shopper status endpoints. What it does not have is a stub pretending to be a provider. An entry in the catalogue is a promise that a merchant can connect it and take money, and shipping one that accepts credentials but cannot charge anything would be a lie told to a real store. So the list stays honest and short.

What the checkout asks for, in order

The checkout collects things in the order they depend on each other. The basket comes first, then the destination, because the delivery fee cannot be resolved until the destination is known. The fee then falls out of your country and city rules. A coupon can be applied. Payment comes last, and the order is created with a sequential number for you and an opaque tracking id for the customer. The cart is re-priced on the server before anything is committed, and stock is checked at the same moment, so a price edited while someone was browsing does not go through at the old figure. See how delivery countries and fees resolve.

A method is not a provider

Posty5 separates the method a shopper picks from the provider that would process it, and the distinction is deliberate: shoppers choose "card" or "cash on delivery", not the name of a processing company they have never heard of. The framework can express card, wallet, bank transfer, buy-now-pay-later and cash on delivery as method types. Only the last of those is available to a store today, because availability depends on a connected provider and there are none.

When the payment step does not appear at all

Because cash on delivery is modelled as a provider like any other rather than as the absence of one, the checkout has no special case for it — and that produces a small, useful behaviour. When only one method applies to a shopper's country and currency, the payment step is not shown at all; the checkout simply names the method it is using. A step that offers a single choice is a step that wastes a tap, so it does not appear.

What the thank-you page can honestly say

The result page reflects the status the server confirmed, never what the return URL claimed — which matters the moment a real provider is connected, because a return URL is something a browser can be talked into. Today the useful consequence is quieter: a cash-on-delivery order carries no payment record at all, and the thank-you page draws no payment line for it. That absence means no online payment was ever started. It does not mean the order is unpaid, and the two must not be read as the same thing.

Guest checkout and cart mode

Two checkout behaviours are yours to set. Guest checkout decides whether a shopper must sign in before ordering; with it on, someone can buy without an account and still track the order by link. Cart mode decides whether the store uses a basket at all, which suits catalogues where people buy one item at a time. Neither has anything to do with payment, and both can be changed after launch. See what a signed-in shopper gets.

Open the Online Store Builder

Checkout settings sit with the rest of the store's configuration, and none of them require a payment provider to be useful.

Frequently asked questions

Can shoppers pay by card on a Posty5 store?

Not today. The framework can express card payments, but the gateway catalogue holds cash on delivery only and no provider adapter is connected.

Is a payment provider coming?

The framework was built to accept one, and adding a provider means writing an adapter rather than changing the checkout. No date is published, and this article will not invent one.

Why is there no payment step on my store?

Because only one method applies. The step is shown when a shopper has more than one option, and the method is simply named otherwise.

My thank-you page shows no payment line. Is that a bug?

No. A cash-on-delivery order has no payment record, so there is nothing to show. It means no online payment was started, not that the order is unpaid.

Can customers use a coupon?

Yes, a coupon can be applied at checkout before the order is placed.

Can people buy without creating an account?

Yes, where you have guest checkout enabled. Order tracking never requires an account.

ADAdvertisement