Compliance

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

• iOS 14.0+: Set your deployment target to iOS 14.0 or later.
• URL callback scheme: Register the SDK callback scheme in Info.plist (default: pxpcheckout). Paze checkout returns to your app at {scheme}://paze. See Implementation.
• Unique URL scheme: Use a scheme that is unique to your app to prevent another app intercepting checkout callbacks.
• App Transport Security: API calls to PXP and Paze use HTTPS. Don't disable ATS globally unless required for local development, and never for production builds.

• Backend session creation: Create sessions on your backend with HMAC authentication. Never embed hmacKey, encryptionKey, API tokens, or Paze credentials in your app binary.
• Environment matching: Use UAT credentials with environment: .test and production credentials with environment: .live.

• USD only: Paze currently supports USD transactions exclusively. The SDK validates currency at presentment and throws SDK1213 for other currencies.
• E-commerce entry type: Set transactionData.entryType to .ecom when initialising the SDK. Paze doesn't support other entry types.
• US shoppers: When provided, phone numbers must be in US E.164 format without the + prefix.
• Card networks: Visa, Mastercard, and Discover are supported.

• Client ID: Valid Paze client ID in the session at session.allowedFundingTypes?.wallets?.paze?.clientId. Validated at presentment. Missing values trigger SDK1202.
• Profile ID: Optional field on the session response (allowedFundingTypes.wallets.paze.profileId) for backend or portal configuration. The iOS PazeButtonComponent doesn't read profileId during create-session or complete flows.
• Merchant category code: Required in the session for payment completion on iOS at session.allowedFundingTypes?.wallets?.paze?.merchantCategoryCode. Missing values cause SDK1202A when the SDK builds the complete request.

The component renders official Paze button artwork. Use only the supported PazeButtonStyleConfig values:

• Never store raw card numbers, cryptograms, or network tokens in app storage (UserDefaults, Keychain for payment data, files, or logs).
• Validate all decrypted token data on your secure server before fulfilling orders.
• Implement proper error handling and logging without exposing sensitive payment data.
• Use HMAC authentication for all backend API calls.
• Register a unique URL callback scheme and avoid sharing schemes across unrelated apps.

• Only collect identity data required for checkout (emailAddress, phoneNumber on the component).
• Comply with applicable privacy regulations (CCPA, state privacy laws, App Store privacy requirements, and so on).
• Handle securedPayload and decrypted token data only on your backend when using manual decryption.
• Verify transaction results on your backend before order fulfilment.
• Don't log full securedPayload values or network tokens in production.

After a successful payment:

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

See Implementation.

Paze checkout uses ASWebAuthenticationSession and redirects to {scheme}://paze when complete. Ensure:

• The scheme in Info.plist matches the SDK's PXP_CALLBACK_SCHEME (default pxpcheckout).
• No other app on the device can register the same scheme for a different purpose.
• You don't log or expose callback URLs containing checkout response data in production.

When enabling AVS (performAVS = true):

• Set billingPreference to .all so Paze returns a billing address.
• AVS data is included automatically in the transaction request from the decrypted payload when the SDK submits the transaction.
• AVS results should inform — not replace — your broader fraud strategy.

If you handle decryption on your backend (onPreDecryption returns false), add addressVerification to your server-side transaction request using billing data from the decrypt response.

• Pass device and session data through onPreAuthorisation using PazePreAuthorisationResult.transactionInitData(...).
• Set kountDisabled: true on CheckoutConfig when calling PxpCheckout.initialize(config:) only if your fraud strategy doesn't require Kount device fingerprinting.
• Review Kount screening results before fulfilling high-value orders.

• Use PazeButtonStyleConfig with approved colour, shape, and label values.
• Present the Paze button with equal prominence to other payment methods.
• Provide optional emailAddress and phoneNumber when you have verified shopper identity.
• Implement comprehensive error handling with clear, user-friendly messages.
• Test thoroughly in UAT on physical devices and the Simulator before switching to live credentials.

• Never log or store raw card numbers, cryptograms, or network tokens.
• Fetch session data from your backend at runtime. Don't hardcode credentials.
• Validate decrypted token data and verify transaction results on your backend before order fulfilment.

• Track payment success and failure rates using analytics events.
• Monitor button visibility with onPresentmentResolved.
• Test checkout flows after iOS and SDK updates, including URL scheme handling after app reinstall.