Changelog
Most recent changes are listed first.
Bank debits now clear.
A live bank debit becomes succeeded about 2 business days after it’s sent, once the bank’s
statements show no return, and both payment_intent.succeeded and payment_intent.failed are
sent for bank debits. Sandbox bank debits now settle after 2 business days, not 3. See
BECS Direct Debit.
A live account that isn’t currently active is read-only too.
An activated live account that isn’t currently active already refused payment requests with a
403 live_not_ready error. It now refuses creating, updating or deleting customers, saving
payment methods, and creating, activating or resuming payment plans the same way, as an account
that isn’t activated yet does. Its dashboard says it isn’t currently active and hides the ways to
create them. Reads still work. See
Switching to live.
A live account is read-only until it’s activated.
A live account that hasn’t been activated already refused payment requests with a 403
live_not_ready error. It now refuses creating, updating or deleting customers, saving payment
methods, and creating, activating or resuming payment plans the same way. The dashboard hides the
ways to create them until activation. Reads still work. See
Switching to live.
Scheduled payments wait for a live account’s activation.
A live account’s scheduled payments (payment plan payments and other scheduled card and bank debits) are held, not sent, until the account is activated. They are sent on the first run after activation, including any whose date has passed. See Switching to live.
SMS payment links carry an opt-out, and show their delivery status.
Every payment link SMS now ends with “Reply STOP to opt out”. A customer who replies STOP gets no further SMS from any business on ElasticPay until they reply START, and the payment link form refuses SMS to their number. The payment link page shows whether the SMS was sent and delivered. See SMS Messages.
Failures on our side have their own codes.
A card payment that fails because of a problem on our side, not the card issuer, now fails with
processing_error or processing_timeout, and the customer isn’t charged. A card payment whose result
doesn’t reach us stays processing until we’ve confirmed it with the PSP. See
Payment Lifecycle.
Scheduled payments delayed on our side keep retrying.
A scheduled payment we can’t send on its date because of a problem on our side stays ready and goes
through once the problem is fixed. See Scheduled Payments.
No SMS in sandbox, and a test-mode banner on every hosted page.
A sandbox account never sends SMS: a payment link created with SMS delivery is created, but no message goes out. The card setup page, its confirmation and the payment link pages now show the “Test mode — no real payment will be processed” banner for a sandbox account, as the checkout already did. See Emails in test mode.
Suspended accounts hold scheduled payments.
While an account is suspended, its scheduled payments (payment plan payments and other scheduled card and bank debits) are held instead of sent. They are sent on the next run after the account is reinstated, including any whose date has passed. A deactivated account’s scheduled payments are never sent. See Account states.
Sandbox emails stay in your team.
A sandbox account’s emails now reach only people who joined your organisation themselves and have
confirmed their email address, and carry [Test] in the subject. Give a test customer your own address to see what
they would receive. See Emails in test mode.
Test clocks.
Simulate the passage of time in sandbox: fast-forward payment plan renewals, dunning retries, subscription rollovers, and payment-link expiry. See the Test Clocks guide and What Test Clocks Simulate.
Initial public documentation release.
Covers:
- Payment intent lifecycle and API
- Widget embedding and customization
- Webhooks and event reference
- Recurring payments and setup intents
- Portal: accounts, customers, payment plans
- Error codes and test resources