Guide 12 · Developer docs

Performance, caching, deployment and go-live

How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.

L2–L3
Unit 05 · Go-live

Disabling test providers

A test payment or tax provider left active on a live site produces orders that look real and are not. Which providers to switch off, the check that none is selectable, and the one real order that proves the live setup works.

Who this is for. The commerce implementer launching a store, or a site with a form that takes payment. Afterwards you can list every test provider on the account, prove that none is offered to a shopper, and prove that the live ones move money.

Every store is built against providers that do not move money: a Mock Pay payment method, payment methods in Test Mode, a mock tax provider. Each is a record in the database, shared by every environment of the site. Left active at launch they do not fail, they succeed: a Mock Pay method set never to fail approves every payment, the order is recorded as paid, and nobody notices until the money is counted. That is why this is a named item on the checklist, not part of "check the shop".

What to disable

ProviderThe riskAt go-live
A Mock Pay payment methodPayments are approved or declined by its failure rate setting, and no money movesUntick Active, on every Mock Pay method of the account
Stripe or PayPal with Test Mode onThe provider's sandbox is used: test cards succeed, real cards are not chargedEnter the live keys, then turn Test Mode off
The mock tax provider, on a zone or as the Taxes setting Default providerShoppers are charged the mock provider's fixed rate, and nothing reaches a tax servicePoint every live zone, and the default provider, at the real provider
Avalara in its sandbox environment, Stripe Tax in test modeRates and transactions go to a test accountSwitch to the production account and keys
A form's payment elementEach payment element lists its own payment methodsOpen every form that takes payment and check its methods

A payment method can be set for one site or left for every site of the account, and the checkout lists what it is given. A Mock Pay method created for a test site without a site set is therefore offered on every site of the account.

The check that none is selectable

Do not rely on having clicked the right switches: ask the site what it has. List the payment methods through the REST API, authenticated as an integration, and look for any active method that is a mock or in Test Mode. paymentServiceProviderType is the provider's name in lower case with hyphens, mock-pay for Mock Pay:

Shell
curl -s "$SITE_URL/cdna-api/invoices/payment-methods?properties={id,name,active,testMode,paymentServiceProviderType,site{id}}" \
  -H "Authorization: Bearer $CDNA_TOKEN" \
  | jq '.data[] | select(.active and (.testMode or .paymentServiceProviderType == "mock-pay"))'

No output is the pass; anything printed is a method to switch off. Then open the checkout as a shopper would and read the payment step: the methods shown must be exactly the live ones, and the same on every form that takes payment. Finally, open each tax zone in the admin and the Taxes settings, and confirm the provider of each.

Run the check again after any change to payment or tax settings, and make it one of the recurring checks (Health checks worth automating): a method switched back to Test Mode for a quick debugging session is the same failure a month after launch.

The live check

Switching providers to live is proven only by money moving. On launch day, place one real order on production with a real card for a small amount, then:

  1. Confirm the order and its invoice in the admin, paid.
  2. Confirm the payment in the provider's dashboard, in live mode, for the same amount.
  3. Confirm the tax on the order matches what the tax provider recorded.
  4. Confirm the order confirmation email arrived.
  5. Refund it, and confirm the refund reached the provider and the invoice.

If any step does not happen, the store is not live, whatever the site shows. Fix it before the launch is announced.

Go deeper

Was this page helpful?

Your answer goes to the docs team.