Web Client SDK

Initialize, Checkout, and Complete must be used for all payment actions. CanCheckout can be used to facilitate a dynamic presentation of the Paze button or user interface by checking consumer eligibility, however, it is not explicitly required.

All JavaScript (JS) SDK APIs use JS Promises instead of events or callbacks. The Paze SDK will always respond back with a Promise.

Initialize

Initialize Paze with common state, starting the Merchant session. This is required before calling any other methods and is recommended to start with page load, since it will begin running fraud checks against the consumer’s device. Multiple Merchant sessions may run in parallel.

Initialize Request Parameters

Initialize Request Parameters

Initialize Promise – Resolve and Reject

Initialize Business Errors

Standard errors are enumerated in their own section and are therefore excluded from API-specific tables.

Initialize Code Examples

initialize ({ 
    required Client client;
}) 

// Response – empty

CanCheckout

CanCheckout allows emails to be passed, as does the checkout call. Lookup keys can now also look up the mobile number.

This API checks whether a specified consumer lookup key (email address or mobile number) is known to Paze. If both are passed, the Mobile Number will be used instead of the Email Address. CanCheckout can be used to facilitate a dynamic presentation of the Paze button or user interface only to consumers who are eligible.

The SDK hashes the consumer lookup key before transmitting it.

For full details see CanCheckout Request Parameters

CanCheckout Response Attributes

CanCheckout Promise – Resolve and Reject

CanCheckout Code Examples

checkout({ 
    conditional String emailAddress; 
    conditional String mobileNumber;
    
}) 
// Response  
dictionary {
  required Boolean consumerPresent; 
} 

Checkout

Invoking Checkout launches the Paze user interface (UI) via a popup. The flow can be customized using the actionCode field depending on the intended action of the customer.

• Selecting a card
• Changing their shipping address, or
• Selecting a different card

If actionCode is START_FLOW

• If CanCheckout has not returned TRUE (including instances where CanCheckout has not been called) and the consumer’s lookup key (email address or mobile number) is not provided in the request, the consumer will be prompted to submit it within the SDK’s UI.
• Lookup is performed using the email address or mobile number.
• If the consumer is not found or is ineligible, the SDK will display an in-line error screen so the consumer knows to return to the Merchant’s site.
• If the consumer is found and is eligible, the SDK will proceed normally.
• If CanCheckout has returned TRUE and the consumer’s lookup key was not provided in Checkout, then the SDK’s UI will launch using the lookup key that was provided in CanCheckout.
• Regardless of the response to CanCheckout, if the consumer’s lookup key (email address or mobile number) is provided in Checkout, then the SDK will perform a lookup using the lookup key provided in Checkout before launching the UI. The SDK hashes the Consumer’s lookup key before transmitting it.
• If the consumer is not found or is ineligible, the SDK will return an error so the Merchant can route them to an alternative payment method.
• If the consumer is found and is eligible to check out, the SDK will proceed normally.
• The SDK will render the following screens:
• consumer authentication
• card selection
• shipping address selection or entry (if configured in the Checkout request)
• If actionCode is CHANGE_CARD or CHANGE_SHIPPING_ADDRESS
• The SDK renders only the respective screens to select the card or shipping address.
• The Merchant must start a new checkout/user session (START_FLOW) when:
• Excessive time has elapsed.
• The consumer will see a warning screen six (6) minutes after their last activity in the Paze UI. The SDK will end the consumer’s session and present a timeout screen 8 minutes after the consumer’s last activity (2 minutes after they are shown the inactivity warning).
• The consumer indicates that they would like to use a different email address.
• The response of Checkout will contain masked card, consumer, and billing and shipping address, per the corresponding Checkout API request.

For full details see Checkout Request Parameters.

Checkout Response Attributes

Checkout Promise – Resolve and Reject

Checkout Business Errors

Checkout Code Examples

checkout({ 
    optional String emailAddress; 
    conditionalString mobileNumber;
    optional String sessionId;
    optional Enum actionCode;
    optional Enum intent;
    conditional TransactionValue transactionValue;
    conditional Enum shippingPreference;
    optional Enum billingPreference; 
    optional List<Cobrand> cobrand;
    optional List<String> acceptedShippingCountries;
    optional List<String> acceptedPaymentCardNetworks;
}) 
// Response  
dictionary {
	required String result;    
	conditional JWS<CheckoutResponse> checkoutResponse;
} 

Complete

This API closes the Merchant and consumer sessions (where applicable) and provides a payment identifier and, if requested, the card details required to successfully process the Payment Transaction.

If both the Merchant and consumer sessions have timed out without receiving a valid input, Complete should not be invoked. If it is invoked, Merchants will receive an INCOMPLETE_CHECKOUT error.

The Merchant must incorporate a card-on-file consent check into their own digital property if they intend to use that functionality in Complete.

Card networks handle card-on-file functionality in different ways. Refer to individual card networks’ documentation for clarification and the most up-to-date guidance.

• Visa allows Merchants or their payment service providers to perform a token-for-token swap with a previous payment token. This means that, if the transaction type is BOTH, the dynamic data for CARD_ON_FILE will be identical to the dynamic data for PURCHASE.
• Mastercard has separate tokenization protocols for purchases and cards-on-file. This means that, if the transaction type is BOTH, the dynamic data will vary and need to be handled differently between PURCHASE and CARD_ON_FILE use cases.
• Discover does not support card-on-file functionality. Only PURCHASE is supported for Discover cards.

For a complete listing see Complete Request Parameters.

Complete Request Parameters

Complete Response Attributes

Complete Promise – Resolve and Reject

Complete Business Errors

Complete Code Examples

complete ({
     optional String sessionId; 
     required Enum transactionType
     optional TransactionOptions transactionOptions;  
     conditional TransactionValue transactionValue;
     optional EnhancedTransactionData enhancedTransactionData;
     optional Enum processingNetwork;
  
})
// Response
dictionary {
     required JWS<completeResponse> completeResponse;
}