Checkout on your own site

With the free plugin, pressing Checkout sends your customer to a page at checkout.stripe.com. It is a good page and it is safe, but it is not yours: your header goes, your footer goes, and the address bar changes to somebody else's name at the exact moment somebody is deciding whether to trust you with a card.

Pro puts that same form inside a page of your own. Your header, your footer and your address bar stay put from the first click to the receipt.

Turning it on

Three things, across two tabs, and the order does not matter.

1. Choose where customers pay

On the Settings tab, find Where customers pay and choose your own site rather than Stripe's page.

2. Pick or create the checkout page

The same card asks which page carries the form. Choose one you have already made, or press the button that makes it for you: it creates the page and puts the [bangcart_checkout] shortcode on it in one go.

Pressing that button twice will not make a second page. It notices the one it already made and leaves it alone, which matters because a duplicate checkout page is the kind of mistake you find out about from a customer.

3. Add your publishable keys

On the Stripe tab, two new boxes appear beneath the secret keys, one for test and one for live. They are only there while this feature is switched on.

A publishable key begins pk_test_ or pk_live_, and each box accepts only its own mode's key. If you have read Connecting Stripe you will have been told, correctly, that the plugin needs the secret key and not the publishable one. That was true until this feature existed. The embedded form runs in your customer's browser, and a browser cannot be trusted with a secret key - the publishable key is the one designed to be seen in public, which is the entire reason Stripe issues two.

Nothing here can cost you a sale

This is the part worth reading twice, because it is the design decision that makes the feature safe to switch on before you have finished setting it up.

Until the page and the matching key are both in place, customers pay on Stripe's own page exactly as they always have. Not an error, not a blank page, not a refused checkout - the ordinary hosted checkout that was working yesterday. Only you are told why, on the settings card and on the checkout page itself.

What the customer experiences

The basket's Checkout button becomes a doorway to your checkout page rather than a departure to Stripe. Switch the feature back off and it departs again. Nothing else about the basket changes either way.

One customer holds stock once

A checkout reserves stock for half an hour, so that two people cannot buy the last one. On a page a customer can reload, that raises an obvious question: does a hesitant shopper who wanders off and comes back stack up a second hold, and a third?

No. The payment session is remembered for that tab and offered back, so returning to the page picks up where they left off rather than starting a new reservation. If the basket has changed in the meantime the old session is retired before a new one is made, so there is never more than one hold per customer.

Paying in one tab with another still open

Somebody who pays in one tab and then reloads an older one is taken to their completed order, not shown a fresh payment form for something they have already bought.

A declined card is told the truth

When the payment comes back, the return page asks Stripe what actually happened rather than assuming the customer's arrival means success.

A failed payment says plainly that nothing was charged and that the basket is still there. It never says thank you for an order that does not exist, and the basket is only emptied once Stripe confirms the money was taken. A customer who has just had a card declined is already unsettled; being told they have paid when they have not is how that becomes a support email and a chargeback.

Notes and questions work either way

Stripe's own payment page allows only three short custom fields, which is not enough for a real basket. So order and product notes are collected in your basket, before checkout, rather than on the payment form.

That is why they behave identically whether your customers pay on Stripe's page or on yours. Switching this feature on changes nothing about how you ask a customer for an engraving name or a delivery instruction.

If Pro is not active

Customers pay on Stripe's own hosted page, exactly as they did before you switched this on. Nothing is refused, no sale is lost, and no customer sees an error.

Your checkout page stays where it is and your publishable keys stay saved, ready for Pro's return. This is the promise every Pro feature makes: a paused feature, never a broken shop. See What Bang! Cart Pro adds.

What this is not

It is not a payment form built by this plugin. Every field a customer types into is Stripe's own, which is what keeps your site out of scope for handling card data and keeps the payment methods your Stripe account offers working without any work from you.

It is also not a checkout you can restyle field by field. You get your page around Stripe's form, not control of the form itself. If you want the shop's colours reflected in it, that is set under Branding in your Stripe Dashboard, the same as it was for the hosted page.