@tuppence/js 0.1.0 → 0.1.1

package/README.md

@@ -1,6 +1,6 @@
 # @tuppence/js
 
-Take a card in the browser for a [Tuppence](https://tuppence.ai) payment — through Stripe's own
+Take a card in the browser for a [Tuppence](https://tuppence.ai) payment, through Stripe's own
 card fields, never ours. Card details go from the payer's device to Stripe, and never through
 Tuppence, this package, or your code.
 
@@ -35,7 +35,7 @@ form.addEventListener("submit", async (event) => {
 ```
 
 `confirm` presents the card (Stripe's fields make a confirmation token), lets the payer's bank
-check it's them if it asks — in Stripe's own frame — and reads the payment back until it settles.
+check it's them if it asks (in Stripe's own frame), and reads the payment back until it settles.
 If an answer is lost on the way, it reads back what happened: a card is never presented twice.
 A read the server briefly can't answer (a 503, no answer) is sent again, twice at most; a confirm
 never is.
@@ -53,7 +53,7 @@ the charge, and `tuppence.confirmPayment({ clientSecret, elements })` pays with
 ## Bacs Direct Debit
 
 Where the business takes Direct Debit, Stripe's Payment Element offers *Bacs Direct Debit* beside
-cards, and shows the mandate and the Direct Debit Guarantee itself — don't hide or clip it. A
+cards, and shows the mandate and the Direct Debit Guarantee itself. Don't hide or clip it. A
 debit takes a few working days, so `confirm` answers at once with the payment `processing`:
 
 ```js
@@ -66,7 +66,7 @@ if (payment.status === "processing" && payment.payment_method_type === "bacs_deb
 
 Nothing waits for `succeeded`: that (or `failed`) arrives days later, by webhook
 (`payment.succeeded`, `payment.failed`). Stripe emails the payer to confirm the mandate.
-Where a debit can't be used — a booking's deposit, a till, a credit top-up — the payment's
+Where a debit can't be used (a booking's deposit, a till, a credit top-up), the payment's
 `excluded_payment_method_types` says so, and the sheet leaves Bacs out.
 
 ## Apple Pay, Google Pay and Link on a store
@@ -133,7 +133,7 @@ const result = await sheet.confirm();
 
 An environment with no Stripe sandbox behind it runs Tuppence's simulated gateway: there are no
 card fields (`elements()` answers `null`, and a sheet's `error` event says so), and you name one
-of Stripe's test cards instead —
+of Stripe's test cards instead:
 `confirmPayment({ clientSecret, testPaymentMethod: "pm_card_gb" })`. `tuppence.config.stripe`
 says which gateway you are on.
 
@@ -148,7 +148,7 @@ const tuppence = await loadTuppence("pk_test_…", { apiBase: "https://…" });
 
 ## Your page's Content-Security-Policy
 
-Stripe.js is loaded from `js.stripe.com` — never bundled — when card fields are first asked for.
+Stripe.js is loaded from `js.stripe.com`, never bundled, when card fields are first asked for.
 Allow what Stripe's integration security guide lists, and Tuppence's API, beside your page's own
 sources (`script-src 'self'`, and so on):
 
@@ -167,8 +167,8 @@ The publishable key and client secrets travel in headers, never in a URL, and no
 
 ### No integrity hash on Stripe.js
 
-Stripe serves Stripe.js from `js.stripe.com` and changes it in place — fixes, and the fraud
-signals Radar relies on — so it cannot carry a Subresource Integrity (SRI) hash: Stripe does not
+Stripe serves Stripe.js from `js.stripe.com` and changes it in place (fixes, and the fraud
+signals Radar relies on), so it cannot carry a Subresource Integrity (SRI) hash: Stripe does not
 support one, and does not allow Stripe.js to be bundled or hosted anywhere else. The SDK loads it
 through Stripe's own loader (`@stripe/stripe-js`), with no `integrity` attribute. What keeps the
 page's scripts in check is the policy above: scripts only from your origin and Stripe's.
@@ -177,7 +177,7 @@ page's scripts in check is the policy above: scripts only from your origin and S
 
 ### What this package never does
 
-It never renders a card field of its own — Stripe's iframes take the card — and never carries
+It never renders a card field of its own (Stripe's iframes take the card) and never carries
 Stripe.js. Its build fails if either creeps in: the bundle and every published file are checked
 for an `<input>`, for the names card fields go by (`cardnumber`, `cc-number`, `cvc`…), and for
 Stripe.js's own code.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tuppence/js",
-  "version": "0.1.0",
-  "description": "Take a card in the browser for a Tuppence payment — through Stripe's own fields, never ours.",
+  "version": "0.1.1",
+  "description": "Take a card in the browser for a Tuppence payment, through Stripe's own fields, never ours.",
   "license": "MIT",
   "homepage": "https://docs.tuppence.ai",
   "repository": {