Skip to main content
Paylead runs two fully isolated environments. Build and validate against the sandbox. Switch to production only after Paylead approves your integration. Why this matters. Sandbox and production do not share data, tokens, or Consumers. A token from one will not work against the other. Treat them as two separate platforms.

Comparison

Sandbox and production have full feature parity. The only differences are the URL, the data they hold, performance, and who is responsible for what. Each Program gets a dedicated subdomain keyed by its programRef, a unique identifier issued by Paylead at onboarding. Substitute it into the URLs below; the rest of the host is fixed per environment.
PropertySandboxProduction
Base URL
DataTest entities you create yourself, no PIIReal Consumers, real transactions
PersistencePermanent (you manage your own cleanup)Permanent
AccessGranted on signupGranted after sandbox validation
Feature set100% of production featuresSame
Webhook deliverySandbox signing secretProduction signing secret
PricingFreePer contract
Sandbox and production hold separate datasets. IDs created in sandbox never appear in production and the reverse.

Pick the right environment

You are…Use
Building the first integrationSandbox
Running automated tests in CISandbox
Demoing to internal stakeholdersSandbox
Validating PSD2 transaction ingestionSandbox first, then Production
Serving real ConsumersProduction (staged, see below)

Production rollout phases

Going live in production is staged. Paylead validates your integration at each phase before opening the next:
PhaseAudiencePurpose
AlphaA restricted, controlled cohort (typically your own test users and Paylead team)Paylead validates the end-to-end integration against production plumbing.
BetaA limited group of real ConsumersPilot run at small scale before full availability.
General availabilityAll your ConsumersFull production rollout.
Paylead gates the move from one phase to the next; coordinate the schedule with your account manager.

Switching environments in code

The only differences between environments are the base URL and the token. Keep both behind environment variables.
Code examples coming soon. The Paylead API (v2) is still under construction. Request and response examples for this section will be published once the contract is finalized. In the meantime, contact your Paylead account manager for early-access details.
Never hardcode the base URL or token in source. A single misconfigured deploy can leak production data to a staging service.

Get sandbox access

Paylead grants sandbox access when you sign up for an account in Shift. If you are not yet a Program Manager, contact your Paylead representative.

Promote to production

1

Complete sandbox integration

Implement the Paylead API endpoints you need against the sandbox. Cover every endpoint you will call in production.
2

Run the validation suite

Paylead provides an integration checklist. Execute end-to-end scenarios: Consumer enrollment, transaction ingestion, Reward attribution, Ventilation export.
3

Request production review

Open a ticket in Shift or contact your Paylead representative with your integration summary. Paylead reviews logs and edge cases.
4

Receive production credentials

Once validated, generate your production tokens in Shift’s Settings > API Keys. Roll them through your secret manager.
Your services run against api-{programRef}.paylead.eu with production tokens. Sandbox tokens stay in CI and staging.

Sandbox limits

The sandbox is shaped for development, not load testing.
  • Data is not reset automatically; you manage your own cleanup.
  • Per-Program rate limits apply. See Rate limits and confirm your thresholds with your account manager.
  • Feature parity with production is complete. Anything you can do in production, you can do in sandbox.

What’s next

Consumer lifecycle

Enroll Consumers and manage their accounts.

Share transactions

How a transaction becomes an attributed Reward.

Rate limits

Sandbox vs production throughput.