Stripe

Stripe collects card payments, and after one setup step it also collects Apple Pay and Google Pay (see Apple Pay and Google Pay below). It supports the widest currency list of any connectable gateway and both payment experiences: embedded, where Stripe's card fields appear on your own checkout and invoice pages, or hosted, where customers pay on a Stripe page and return when done.

Currencies

USD, EUR, GBP, JPY, INR, AUD, CAD, CHF, NGN, GHS, KES, ZAR, TZS, UGX, RWF, XAF, XOF, CZK, DKK, HKD, HUF, ILS, MXN, NOK, NZD, PHP, PLN, SEK, SGD, THB and TWD.

Stripe does not settle Bahraini Dinar or Kuwaiti Dinar. If you price in those, route them to Adyen and keep Stripe for the rest; see routing currencies between gateways.

Connecting

Go to Settings, then Payment gateways, then Stripe, and run the connect wizard for test mode first. It asks for:

• Secret key: API keys, then Secret key, in your Stripe dashboard. Charges are made with this key.
• Publishable key: API keys, then Publishable key. The browser uses it to mount Stripe's card fields.

Use the test keys (sk_test_, pk_test_) on the test connection and the live keys on live. The wizard's connection test verifies the secret key with Stripe before anything is saved.

Webhooks

After connecting, the setup checklist asks for a webhook. In the Stripe dashboard under Developers, then Webhooks, create an endpoint pointing at the URL shown on the gateway page, then paste its signing secret (whsec_) into the checklist. Every inbound event is verified against it.

Stripe confirms most charges immediately, so charging works before the webhook is set up. Set it up anyway: it is how a 3D Secure check completed later, an asynchronous payment, a refund update or a dispute reaches the right invoice on its own. A dispute that closes against you is recorded on the customer's account as a chargeback automatically (see refunds).

Apple Pay and Google Pay

Wallet buttons cannot appear on any website until that website's domain is registered with your Stripe account. This is Apple's rule, not ours, and it is why the buttons do not simply show up once your keys are in.

Registering takes one press. On Settings, then Payment gateways, then Stripe, the connected mode's checklist has a row for Apple Pay, Google Pay and Link. Pressing Turn on registers the yRecurring domain that serves your checkout and invoice pages with your own Stripe account, then tells you what Stripe says about each wallet:

• Google Pay and Link go live with the registration itself.
• Apple Pay also needs Apple's verification file served from that domain. If it is not in place yet, the row says so in Stripe's own words. Once it is, press the button again and Apple Pay activates.

A wallet can also be switched off in your Stripe dashboard's payment methods. If Stripe reports one as inactive after a successful registration, that is where to look.

Buyers see the buttons above the card fields, and only on a device that actually has the wallet. Nobody is shown a payment method they cannot use. A wallet payment is a card payment on the ledger, saved for renewals in the same way, so nothing downstream changes.

The buttons appear on your hosted checkout and on the payment page of an unpaid invoice. Two cases deliberately keep the card form as the only route:

• Nothing is due today. A trial or a future start has no payment to authorise, so there is nothing for a wallet to approve.
• The checkout requires a business tax ID or a required custom field. A wallet sheet can return a name, an email, a phone number and a billing address. It cannot return a VAT number or your own field, so a buyer who tapped would land back in the form they were trying to skip. Making those fields optional brings the buttons back.

Link appears in the setup status because Stripe reports it, but yRecurring does not show a Link button yet.

Saving cards and renewals

Cards are saved without a charge (the customer's update card page, or signup for a trial) through Stripe's zero-charge setup flow, embedded or hosted. A card saved during a paid checkout is stored for renewals as part of the same payment. Renewals and automatic collection then charge the saved card off session, and a card that requires fresh authentication comes back as an action for the customer rather than a silent failure.

Removing a card in yRecurring also detaches it from the customer's record inside Stripe, so nothing is left behind.

Stripe is the one gateway yRecurring can read saved cards out of. If you are moving here from another billing system and keeping the same Stripe account, the importer can fetch your customers' saved cards straight from Stripe rather than asking you for a file, including which card each customer has set as their default, and any ACH or SEPA mandates you hold. See migrating saved payment methods.

Refunds and disputes

Refunds are sent to Stripe against the original payment and normally confirm right away; a refund on a slower rail stays in processing until Stripe's webhook confirms it. See refunds. Chargebacks raised at Stripe appear on the payment's activity trail automatically.

Test cards

Card	Number	Notes
Visa, succeeds	4242 4242 4242 4242	any future expiry, any CVC
Declined	4000 0000 0000 0002	generic decline
Insufficient funds	4000 0000 0000 9995
3D Secure required	4000 0027 6000 3184	approve or fail the challenge

Run the whole rehearsal in test mode: sign up through your checkout, watch the invoice get paid, fail a payment on purpose and watch dunning pick it up.

Limits

• Cards and card-based wallets only for now. Bank debits through Stripe are not yet offered; use GoCardless for bank debits.
• No Bahraini Dinar or Kuwaiti Dinar settlement.