Compliance

Learn about Paze implementation requirements and suggested best practices for Web applications.

Overview

The Paze component follows Paze's digital wallet SDK guidelines for Web implementation. This page outlines key requirements for compliance with Paze branding, security, and data handling standards.

For complete Paze compliance requirements, refer to your Paze merchant agreement and Paze's digital wallet SDK documentation provided during onboarding.

Technical requirements

Domain and SSL

HTTPS required: All Paze implementations must use HTTPS. Localhost is exempt for development.
Valid SSL certificate: Must have a valid SSL certificate from a recognised authority.
Site URL: The SDK passes your page URL to Paze during initialisation for merchant verification.

Browser compatibility

Chrome: Chrome 80+ on all platforms.
Safari: Safari 13.1+ on macOS and iOS.
Firefox: Firefox 75+ on all platforms.
Edge: Edge 80+ on Windows and macOS.

Currency and region

USD only: Paze currently supports USD transactions exclusively.
US shoppers: Identity validation requires US phone numbers in E.164 format.
Card networks: Visa, Mastercard, and Discover are supported.

Paze account

Client ID: Valid Paze client ID configured in the Unity Portal.
Profile ID: Optional profile ID if provided by Paze.
Environment matching: Use UAT credentials with environment: 'test' and production credentials with environment: 'live'.

Button branding requirements

The component renders Paze's official <paze-button> web component. Use only the supported style values:

Requirement	Description	Status
Equal prominence	Paze button presented with equal prominence to other payment methods.	required
Approved colours	Only use supported colour values: `white`, `whitewithoutline`, `midnightblack`, `pazeblue`.	required
Approved shapes	Only use supported shape values: `default`, `rectangle`, `pill`.	required
Approved labels	Only use supported label values: `checkout`, `check out with`, `Donate with`.	required
Native button element	Do not replace the `<paze-button>` with a custom-styled alternative.	required
Responsive design	Button scales appropriately on all devices.	required

Security and data handling

Security requirements

Never store raw card numbers, cryptograms, or network tokens in client-side storage.
Validate all decrypted token data on your secure server before fulfilling orders.
Implement proper error handling and logging without exposing sensitive payment data.
Keep SSL certificates up to date.
Use HMAC authentication for all backend API calls.

Data handling requirements

Only collect identity data required for presentment (emailAddress, phoneNumber).
Comply with applicable privacy regulations (CCPA, state privacy laws, etc.).
Handle securedPayload and decrypted token data only on your backend.
Verify transaction results on your backend before order fulfilment.
Do not log full securedPayload values or network tokens in production.

Backend verification

Always verify payment results on your backend. Frontend callbacks can be manipulated and should not be the sole basis for order fulfilment.

After a successful payment:

Retrieve the transaction status from the PXP API using systemTransactionId.
Confirm the amount and currency match your order.
Only then fulfil the order or grant access to digital goods.

Fraud controls

Address verification (AVS)

When enabling AVS (performAVS: true):

Set billingPreference: "ALL" so Paze returns a billing address.
AVS data is included automatically in the transaction request from the decrypted payload.
AVS results should inform — not replace — your broader fraud strategy.

Kount risk screening

Pass device and session data through onPreAuthorisation.
Set kountDisabled: true on SDK initialisation only if your fraud strategy doesn't require Kount.
Review Kount screening results before fulfilling high-value orders.

Best practices

Implementation

Use the official <paze-button> element with approved colour, shape, and label values.
Present the Paze button with equal prominence to other payment methods.
Choose static or dynamic presentment based on whether you can supply shopper identity at render time.
Implement comprehensive error handling with clear, user-friendly messages.
Test thoroughly in UAT before switching to live credentials.

Security

Never log or store raw card numbers, cryptograms, or network tokens.
Validate decrypted token data and verify transaction results on your backend before order fulfilment.
Keep SSL certificates up to date.

Monitoring

Track payment success and failure rates using analytics events.
Monitor button visibility with onPresentmentResolved in dynamic presentment mode.
Regularly test payment flows across supported browsers and devices.