Two ways, use either or both: Stripe can email its own receipt, and the plugin can attach its own PDF receipt to the order emails - choose Plugin receipt<\/em> under Invoice \/ receipt document on the Emails tab. A fresh install has this set to None<\/em>, so pick one if you want a document sent.<\/p><\/dd>\nCan I use my own products, not Stripe's?<\/h3><\/dt>\nYes. Products added here are sold and priced normally; they are just not tracked as Stripe products in Stripe's reporting.<\/p><\/dd>\n
Can customers collect in person?<\/h3><\/dt>\nYes. Switch a zone on and leave its postage prices empty.<\/p><\/dd>\n
Is it translation-ready?<\/h3><\/dt>\nThe storefront and most of the admin are. A translation template is included in \/languages.<\/p><\/dd>\n\n<\/dl>\n\n\n
3.5.0<\/h4>\n\n\n- The buyer's confirmation email now includes a Cancellation and returns section, on by default, editable on the Emails tab. UK distance-selling law requires this information in the email itself - a link to a returns page does not count - and missing it is expensive: no cancellation notice and the customer's 14-day return window stretches to as long as a year; no note that the customer pays return postage and the shop pays it instead. The default wording covers the 14-day right and how to use it, who pays return postage, when the right does not apply, faulty-goods rights, and the complaints route. Edit it to match how you actually handle returns, or switch it off if these details already reach every customer another durable way.<\/li>\n
- New Policy pages card on the Settings tab: your Terms of service, Privacy policy and Returns policy URLs. They are linked from the buyer's confirmation email under the cancellation wording. Each URL is checked when you save - a page that does not answer gets a warning, not a refusal, because a staging site behind a password fails the same check silently at Stripe's end too.<\/li>\n
- The same card explains the two Stripe Dashboard settings that put \"By placing your order, you agree to our Terms of Service and Privacy Policy\" under the Pay button - both are needed, Stripe's error message does not say which one is missing, and neither can be set by a plugin.<\/li>\n
- A delivery zone somehow saved with priced postage but no countries can no longer take a posting order. Stripe attaches the postage and the country list together, so this state used to create a payment with no postage charged and no delivery address collected - the customer paid a total the basket never showed, and the shop had an order with nowhere to send it. Checkout now refuses with a clear message instead, before any stock is reserved. Collection orders are unaffected: collecting needs no countries.<\/li>\n
- A source comment now records why the basket's Checkout button may be worded freely: it only opens Stripe's payment page. The button that takes the money is Stripe's own Pay button, which is the one the button-labelling law governs, and Stripe keeps it compliant.<\/li>\n
- Test emails can now be sent to any address you type, with your own suggested. Mail from a site to its own domain often never leaves the server, so a test to a different domain - a Gmail or Outlook inbox - is the one that proves delivery. The address is remembered for next time, and a mistyped address refuses loudly instead of quietly testing the wrong inbox.<\/li>\n<\/ul>\n\n
3.4.1<\/h4>\n\n\n- The Page overlay control on the Design tab now stays editable in both basket placements. Previously it sat with the floating-only settings, so it went grey in self-placed mode even though the overlay still dims the page there. Behaviour and saved values are unchanged.<\/li>\n
- The floating corner button's live preview now sits in a framed Preview panel beside its controls, matching the checkout styling preview.<\/li>\n<\/ul>\n\n
3.4.0<\/h4>\n\n\n- Multiple shipping zones. Every zone you switch on now sells: customers pick their region in the basket, and each zone prices at its own rates. The Add zone button sits under your zones on the Shipping tab.<\/li>\n
- New Page overlay control on the Design tab: choose the colour and strength of the tint that dims your page while the basket is open. Defaults to the indigo the plugin has always used, so nothing changes until you change it.<\/li>\n
- A refreshed wordmark in the admin header, and the admin and fresh-install storefront colours now follow its blue. Shops that have saved their own styling keep it, exactly as always.<\/li>\n
- The plugin's admin styling and scripts, and the storefront basket's styling and scripts, now load through WordPress's enqueue system (wp_add_inline_style \/ wp_add_inline_script on registered handles) instead of printing style and script tags directly.<\/li>\n
- The description no longer compares this plugin with other plugins - it just says what this one does.<\/li>\n
- Wording: notes about settings made by an add-on that is not active now state that fact plainly, with no product names, no paused badges pointing anywhere, and nothing offered for sale from a working screen.<\/li>\n<\/ul>\n\n
3.3.5<\/h4>\n\n\n- Fix: pressing Recount now tells you the answer instead of telling you to wait for it. The confirmation still said the total would \"reappear here once it is complete\" - wording written for the background-only count in 3.3.3 - while 3.3.4 printed the finished figure directly beneath it. A message that tells you to wait for something already on the screen sends you away and back to check.<\/li>\n
- The notice now reports what actually happened: the new total and order count when the count finished in the press, that it is carrying on in the background when the history is too long for one request, or that there are no paid orders to total yet.<\/li>\n<\/ul>\n\n
3.3.4<\/h4>\n\n\n- Fix: pressing Recount, or landing on Orders for the first time, now counts straight away instead of queueing the work. 3.3.3 handed the whole job to WP-Cron - including for a shop whose entire history is a single request - so the press made no Stripe call at all, and on a site with WP-Cron switched off the total never appeared. The first slice now runs on the spot; only a longer history hands off to the background.<\/li>\n
- Fix: a count in progress now advances on Orders tab loads whenever the queued background slice is overdue, so a site with WP-Cron disabled finishes over a few page views rather than never.<\/li>\n
- Only the Orders tab pays for that first request - the other tabs fetch the order list for the \"to post\" badge as they always did, and spend nothing extra on a figure they do not show.<\/li>\n<\/ul>\n\n
3.3.3<\/h4>\n\n\n- New: the Orders tab now shows what the shop has taken, all time, above the orders. Gross, in the shop's currency, with the order count beside it - and it says plainly that it is before Stripe's fees and any refunds, because a figure an owner acts on should not need explaining.<\/li>\n
- It is counted, not guessed. The Orders tab only ever asks Stripe for the 25 most recent orders, so adding up what is on screen would have printed the same number for a shop with 25 orders and a shop with 2,500. The whole history is read once in the background instead, a slice at a time, and no figure is shown until that count is complete - a half-read history is not a smaller total, it is a wrong one.<\/li>\n
- After that it stays current for nothing. The admin already fetches recent orders on every tab of this plugin; new orders are counted from that list, so the ordinary day costs no extra request at all. A shop busy enough to outrun it falls back to a background catch-up rather than holding up the page.<\/li>\n
- Only paid orders count. An async bank payment that has not cleared is not money yet, and an order that needed no payment is not takings.<\/li>\n
- Test and live totals are separate and always were. Clear test order data now removes the test total with the rest of the test notes, and never touches the live one.<\/li>\n
- A shop that has taken orders in more than one currency is told so rather than shown a total that adds them together.<\/li>\n
- Recount, beside the figure, rebuilds it from Stripe from scratch - for after a refund, or any time the number deserves checking.<\/li>\n<\/ul>\n\n
3.3.2<\/h4>\n\n\n- Setting the webhook up by hand no longer breaks delayed bank payments. The hand-setup instructions on the Stripe tab named one Stripe event to tick; the one-button setup beside them has always subscribed four. Anyone who followed the written route silently lost every Bacs or bank-debit order - paid for, never completed. All four events are now listed, built from the plugin's own list so the two can never drift apart again.<\/li>\n
- Those instructions now also explain customer.created, the event Verify connection now uses to prove the connection without taking a payment.<\/li>\n
- The connection check now says plainly what a missing async_payment event costs a shop, instead of mentioning it in passing.<\/li>\n
- The Emails tab named a \"Check connection\" button that does not exist - the buttons are Verify connection now and Re-check only.<\/li>\n
- The translation template was a version behind: it still offered translators three strings 3.3.1 had already replaced, and omitted the replacements, so that work was wasted and those lines stayed English. It is rebuilt from the shipped code.<\/li>\n<\/ul>\n\n
3.3.1<\/h4>\n\n\n- The Documentation button in the admin header is live - it opens the new documentation site at bangplugins.com\/docs\/cart.<\/li>\n
- Start here: the self-placed basket step now points at the Design tab, where the shortcode's Copy button actually lives - both the wording and its Open button still said Settings after 3.3.0's tab split.<\/li>\n
- The Email colours hint now names the real control, Save changes - there is no \"Save colours\" button.<\/li>\n
- readme: the install steps describe the one-button webhook setup (adding it by hand remains a fallback), and the plugin's own PDF receipt is described instead of implying all receipts live in Stripe.<\/li>\n
- Housekeeping: seven code comments still said \"Settings tab\" for controls that moved to the Design tab in 3.3.0.<\/li>\n<\/ul>\n\n
3.3.0<\/h4>\n\n\n- Hardening release: rate-limited public endpoints, refresh-safe admin actions, crash-safe order fulfilment, multi-page PDF receipts, cross-tab basket sync, an accessibility pass (visible focus, keyboard product cards, AA contrast), and a set of correctness fixes across discounts, stock metadata, coupon counters and currency validation. Full detail in changelog.txt.<\/li>\n
- New default storefront palette - a clean indigo-and-blue base for your own styling (existing stores keep their current look automatically; everything stays configurable in Checkout styling).<\/li>\n
- The admin's Settings tab is now two tabs: Design (checkout styling, basket placement, previews) and Settings (shop identity, status, thank-you page); stock messages moved beside the stock levels on Products.<\/li>\n<\/ul>\n\n
3.2.9<\/h4>\n\n\n- The large-order enquiry button now closes the basket when it is clicked. If it points at a section on the same page, the basket no longer sits open over whatever the page scrolls to.<\/li>\n<\/ul>\n\n
3.2.8<\/h4>\n\n\n- The per-zone large-order message is now tucked behind a switch in each zone - \"Give this zone its own large-order message\" - instead of always showing. Off (the default), the zone quietly uses the shop-wide Large orders settings, so a zone is no longer a wall of text repeating the option that already sits below it. Turn the switch on only where you want different wording.<\/li>\n
- The large-order enquiry button now opens the contact page in the same tab, not a new one.<\/li>\n<\/ul>\n\n
3.2.7<\/h4>\n\n\n- New choice on the Discounts tab: let a customer's discount code apply on top of an automatic discount. Off by default. With it on, the automatic discounts (quantity, sale, order value) still only ever apply one at a time, and then the code comes off on top - so a code and a sale can combine, the way most shops work. The total can never fall below zero, and free delivery is unaffected.<\/li>\n
- Tidied the wording throughout so the plugin no longer talks in terms of \"jars\" - the examples now speak of \"items\", since you might be selling anything.<\/li>\n<\/ul>\n\n
3.2.6<\/h4>\n\n\n- The {limit} and {over} placeholders in the Large orders settings are now click-to-copy too, so you can drop them straight into your message.<\/li>\n
- Widened the Enquiry link and Button wording boxes on the Large orders card (and the matching per-zone fields) - they were cramped to a fraction of their proper width.<\/li>\n<\/ul>\n\n
3.2.5<\/h4>\n\n\n- Every shortcode shown in the admin is now click-to-copy. The dedicated Copy buttons stay; on top of that, any shortcode woven into a line of help text - on Start here, Products, Settings and elsewhere - can be clicked to copy it, so you never have to select it by hand.<\/li>\n<\/ul>\n\n
3.2.4<\/h4>\n\n\n- Large orders no longer have to dead-end. On the Shipping tab you can now reword the \"too many to post\" message and, if you like, add a link so oversized baskets get a button through to your contact page instead of a flat \"please remove some\". Set one message and link for the whole shop, or a different one per zone.<\/li>\n<\/ul>\n\n
3.2.3<\/h4>\n\n\n- Bang! Cart now sits high in the left-hand admin menu, just below Dashboard, instead of down by Comments - fewer plugins to scroll past to reach your shop.<\/li>\n
- New quick-access item in the top admin toolbar: a Bang! Cart menu with shortcuts to Orders, Products, Settings and Stripe, on every admin and front-end page. Shown only to users who can manage the shop.<\/li>\n<\/ul>\n\n
3.2.2<\/h4>\n\n\n- A clean bill of health from WordPress's official Plugin Check tool: 228 errors and 106 warnings, now zero. Every echoed style value is escaped, every translatable string with a placeholder carries a translators note, every form field is unslashed and sanitised at first touch, and the few deliberate exceptions (token-authenticated email links, the uninstall sweep, the migration's one-time scan) now say in code exactly why they are what they are.<\/li>\n
- Fixed along the way: the Start here checklist's placement scan now also recognises the pre-rename shortcode names, so a shop built before 3.2.0 is no longer told its button is missing.<\/li>\n
- Tested up to WordPress 7.0. The readme changelog now keeps recent versions only; the full history back to 2.0.0 ships in changelog.txt.<\/li>\n<\/ul>\n\n
3.2.1<\/h4>\n\n\n- The webhook section's hand-setup note now links straight to the Developers - Webhooks page of your Stripe dashboard, in the mode that matches the key above it - the same courtesy the API-key boxes got in 3.1.11.<\/li>\n<\/ul>\n\n
3.2.0<\/h4>\n\n\n- The plugin is now Bang! Cart for Stripe - a new name, same shop. Everything renames itself: settings saved under the old internal prefix are carried over automatically the first time the new version loads, and nothing needs re-entering.<\/li>\n
- Old links keep working forever: order-status and receipt links in emails already sent, shortcodes already pasted into pages, and the webhook address stored in Stripe's dashboard all answer exactly as before.<\/li>\n
- If you added the old override constant to wp-config.php, it is still honoured.<\/li>\n<\/ul>\n\n
Earlier versions: the complete history back to 2.0.0 ships in this plugin's changelog.txt.<\/p>","raw_excerpt":"Sell with Stripe from your own pages: buy buttons anywhere, a fast polished shopping cart, checkout on Stripe's payment page.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/348522","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=348522"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/bangplugins"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=348522"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=348522"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=348522"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=348522"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=348522"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=348522"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}