Checkout keys and cashier keys
Client-side payment sessions require public credentials that cannot authorise capture, refunds or voids. Checkout authentication keys separate browser and mobile SDK access from restricted cashier actions through rotating, server-only cryptographic pairs.
- Category
- Developer
- Capabilities
- 6
- Available on
- All plans
Security engineers require strict separation between public payment interfaces and backend processing to prevent credential leakage. When initialising drop-in components or mobile SDKs, client-side requests demand distinct public identifiers that cannot authorise fund capture, protecting the application layer against malicious payload manipulation or replay attacks.
Cardflo issues checkout authentication keys specifically for instantiating frontend payment sessions, keeping sensitive card data distinct from merchant server environments. The orchestration platform subsequently routes these tokens to acquirer partners using separate cashier key credentials, ensuring financial execution occurs strictly through highly restricted, server-only cryptographic pairs.
Implementing checkout and cashier keys provides robust tokenisation, isolating sensitive payment data from front-end interactions. This architectural design significantly enhances PCI DSS compliance and strengthens overall security for your payment flows.
Checkout keys and cashier keys overview
Cryptographic separation forms the basis of secure client-server payment architectures, ensuring frontend applications only possess the minimum credentials required to securely tokenise cardholder data. Engineers integrate public checkout credentials to instantiate payment sessions, rendering forms and SDKs without exposing sensitive transaction controls to the browser.
Cashier keys then authorise backend capture, refund and void commands, verifying that financial actions originate from a trusted merchant server. This page covers the generation, rotation and application of these specific cryptographic pairs, distinct from machine-to-machine tasks covered in service account management, asynchronous updates found in webhooks, or test mode credentials detailed in sandbox environment.
By establishing clear credential boundaries, technical teams prevent malicious actors from initiating unauthorised transactions while enabling Cardflo to securely route encrypted payloads to designated acquirer partners based on merchant logic.
How checkout keys and cashier keys works
Public checkout initialisation
Developers embed the public checkout credential string within client-side code to instantiate secure payment elements or mobile software development kits. This identifier authenticates the frontend session with Cardflo, allowing the browser to securely collect card details, apply immediate tokenisation and generate a one-time payment intent without exposing the merchant to raw PAN data or authorising final financial capture.
Secure cashier authentication
Once the frontend successfully generates a payment token, the client application passes this safe string to the merchant backend. The server then constructs a secure HTTP request, attaching the restricted cashier key alongside the token. This backend request authorises Cardflo to process the actual transaction, forwarding the payload to the correct acquirer partner network for final approval.
Key pair rotation processes
Security engineers execute scheduled rotation of active credentials by generating secondary key pairs within the merchant console. Systems administrators deploy the new public strings to frontend applications and update backend secrets simultaneously. Upon verifying successful transaction execution using the new pair, legacy keys are manually revoked or set to expire automatically to maintain strict security hygiene.
Why checkout keys and cashier keys matters
Eliminating client-side capture risks
When payment architectures utilise identical credentials for both session initialisation and transaction capture, compromised browser environments grant attackers the ability to initiate unauthorised charges. Enforcing strict separation between public identifiers and private cashier strings ensures that exposed client-side values remain useless for financial operations, protecting merchant revenue and lowering systemic risk.
Continuous operation during key rotation
Static credentials present a severe security vulnerability over time. Supporting rotating payment keys without dropping active sessions allows engineering teams to adhere to strict compliance policies. Providing dual active key states ensures that active checkout sessions complete successfully on the legacy identifier while new traffic routes via the updated cryptographic pair.
Regulatory notes for checkout keys and cashier keys
PCI DSS compliance and credential scope
The Payment Card Industry Data Security Standard mandates strict logical separation between public-facing data collection systems and internal financial processing infrastructure.
Utilising heavily restricted checkout authentication keys significantly limits the scope of client-side vulnerabilities, as this public string only permits the initial generation of encrypted tokens.
By processing actual financial captures through securely stored backend strings, engineering teams prevent their merchant servers from ever touching raw Primary Account Numbers.
The tokenised payload travels safely through the orchestration layer directly to acquirer partners, reducing the overall merchant compliance burden to a simplified self-assessment questionnaire.
Cryptographic standardisation and secure storage
Financial scheme rules explicitly require that any credential capable of authorising live money movement must be protected by robust cryptographic algorithms and rotated following strict enterprise security protocols.
Merchant systems must transmit these cashier identifiers over verified transport layer security connections to prevent man-in-the-middle interception during processing.
Enforcing regular credential rotation schedules directly reflects recognised information-security practice for access control and secret management. Maintaining distinct architectural environments for testing and production ensures that live cashier credentials remain totally isolated, mitigating the risk of accidental exposure during complex software deployment or debugging exercises.
Checkout keys and cashier keys use cases
Single page checkout initialisation
A single page checkout must expose a public checkout key to initialise the client-side SDK without revealing the secret cashier key used to create or confirm payment sessions. Cardflo separates browser-safe credentials from server-held secrets and supports scoped replacement when a public key is exposed.
Embedded cart credential isolation
A WooCommerce or Shopify integration may render Cardflo payment components through a theme, extension or storefront script where checkout authentication keys are visible to the browser. Cardflo provides public keys for client initialisation while secret cashier keys remain in protected server configuration, outside templates and source control.
Cashier key rotation rollout
A production cashier key may require scheduled rotation after personnel changes, repository exposure or an internal cryptographic policy deadline, without interrupting active checkout sessions. Cardflo supports controlled key replacement, allowing engineering teams to deploy the new secret, validate payment creation and retire the previous credential after cutover.
Multi-brand storefront key separation
An organisation operating several branded storefronts needs separate checkout keys so an exposed client credential cannot be reused across unrelated domains or applications. Cardflo enables distinct key allocation and rotation per storefront, while finance and security teams retain central visibility over which public and cashier credentials remain active.
Checkout keys and cashier keys by the numbers
Industry standards suggest that offloading data capture to hosted components via client-side keys can reduce the number of applicable PCI requirements by over 90 percent.
Standardised key-based architectures typically allow developers to implement a basic secure checkout flow within approximately two working days of development time.
Professional payment gateways require 100 percent of server-side requests to be authenticated via a private key to ensure the integrity of the transaction lifecycle.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with Checkout keys and cashier keys
- Restrict client-side payment SDKs using public checkout credentials that cannot initiate fund capture or refunds.
- Authorise server-side capture requests using secure cashier authentication strings passed strictly via backend environments.
- Mitigate credential compromise through enforced, zero-downtime rotation schedules for all primary public checkout identifiers.
- Separate frontend token generation from financial execution to bypass merchant servers and maintain PCI compliance.
- Revoke deprecated public identifiers instantly via the dashboard without interrupting ongoing cashier processing routines.
- Isolate cryptographic layers before Cardflo routes encrypted payloads to corresponding acquirer partners for authorisation.
A short scoping call, then a written plan for your MIDs.
Questions about Checkout keys and cashier keys
Where should checkout authentication keys be stored across browser and server environments?
Public checkout keys may be embedded in approved client-side applications because they identify the checkout integration without authorising privileged payment actions.
Secret cashier keys must remain in server-side secret storage, such as an encrypted secrets manager, and must never appear in browser bundles, mobile application packages, source control or client-visible logs.
Separate keys should be maintained for each environment and application so exposure can be contained and credentials rotated without affecting unrelated integrations.
What happens to active payment sessions during credential rotation?
Cardflo supports zero-downtime key rotation by allowing two active pairs to exist simultaneously within a single merchant environment. When security teams generate new checkout authentication keys, the legacy keys remain valid for a predetermined overlap period.
Sessions initialised under the old public string can still be captured using the corresponding legacy cashier identifier. Once the frontend deployment completes and new traffic utilises the updated credentials, administrators permanently revoke the deprecated keys from the dashboard without interrupting live transaction flow.
Can a compromised public identifier be used to issue refunds?
Public credentials possess no administrative or financial privileges, preventing their use for refunds, voids or captures. If a malicious actor extracts the public string from a merchant website, they can only generate empty payment session tokens.
Refund requests require secure cashier authentication through backend API endpoints, authenticated by the private cryptographic string. This architectural split guarantees that sensitive financial actions bypass the client entirely, requiring the attacker to breach the merchant backend rather than simply inspecting browser traffic.
How are these specific payment API keys securely delivered?
Upon generating a new cryptographic pair, the Cardflo console displays the secure cashier string exactly once. Security engineers must immediately copy and store this value in an encrypted vault or secret management system, as it cannot be retrieved again.
The public checkout string remains visible within the dashboard for deployment into frontend configuration files. This strict delivery protocol prevents lateral movement risks, ensuring that individuals with simple dashboard access cannot extract historical secret strings to authorise unauthorised backend transactions.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.