Accept Wallet payments (ApplePay & GooglePay) - Partner software managed payment page
Introduction
The implementation of Wallet Payments via a Partner software managed payment page allows users the ability to submit a single wallet eCommerce payment via Apple Pay or Google Pay through the SaaS own payment page and returns a result in real-time. This functionality is available for single real-time payments only via the SaaS payment page and using the ‘tokenised card transaction model’ for Apple Pay or Google Pay specifically. The payment can be a complete payment that will be processed, and the funds settled to the business, or it can be a pre-authorisation that will hold the funds until you process a pre-authorised card transaction, or the pre-authorisation expires.
To integrate Apple Pay or Google Pay into your payment page, you will need to have the integration
approved by Apple and/or Google to certify your payment page. Once the Apple Pay or Google Pay
integration has been certified; you can jump to the relevant pay type below which will guide you through the API and payment flow to send Payrix a tokenised wallet payment.
Wallet Payments only available for single real-time transactions
Not available when electing to save the payer details.
o Wallet Payments can be linked to an existing payer record.
o "SavePayer" property must be set to false or not included in the body of the request.All 3 payer property fields required as a minimum when posting tokenised wallet transaction:
o familyOrBusinessName
o givenName
o EmailPre-auth process type is supported but not recommended as it is not possible to save the payment details. Should you verify the wallet payment details, the payer can choose a different payment when attempting the next payment.
3-D Secure Authentication not compatible with Wallet Payments
Flowchart to accept card through Partner software managed page
API steps to accept ApplePay eCommerce guest checkout
The process to accept eCommerce guest checkout can be implemented through the below steps:
POST ApplePay - Make a live tokenized card transaction
The same framework is used as the standard ‘tokenized card transaction model’, however as you will notice the string request is slightly different and you will need to change the cardtoken property to googlepaytoken.
Allow up to 5 - 10 seconds to retrieve response and result of transaction request
Result returned
If successful, transaction statuscode: S - Successful
Payment flow complete - Funds to be settled as per business rules
If unsuccessful, transaction statuscode: F - Failed
Payment flow complete - Application to manage collection of failed attempt
If the intitial transaction has failed, you can simply re-direct your end user to the beginning of your checkout page to re-attempt the payment. You will need to supply a unique transaction reference for each transaction attempt.
API steps to accept GooglePay eCommerce guest checkout
The process to accept eCommerce guest checkout can be implemented through the below steps:
POST GooglePay- Make a live tokenized card transaction
The same framework is used as the standard ‘tokenized card transaction model’, however as you will notice the string request is slightly different and you will need to change the cardtoken property to googlepaytoken.
Allow up to 5 - 10 seconds to retrieve response and result of transaction request
Result returned
If successful, transaction statuscode: S - Successful
Payment flow complete - Funds to be settled as per business rules
If unsuccessful, transaction statuscode: F - Failed
Payment flow complete - Application to manage collection of failed attempt
If the intitial transaction has failed, you can simply re-direct your end user to the beginning of your checkout page to re-attempt the payment. You will need to supply a unique transaction reference for each transaction attempt.
How to simulate failed transactions?
When using the test API, the transaction amount gives you the ability to test both successful and failed payments. When the transaction amount has zero cents or a number of cents other than the ones listed below, the test transaction will always be successful. If you provide one of the following numbers for the number of cents you will receive a transaction failed response with the corresponding reason:
31 = Invalid Account
54 = Expired card - Card Only
51 = Declined
61 = Insufficient Funds
96 = Technical failure - Card Only
Compliance requirements
When accepting card or bank account payments through a non-worldpay hosted payment page, the PCI and banking compliance regulations fall under your softwares responsbility. As you may be aware, every organisation that handles card payments must comply with the Payment Card Industry Data Security Standard (PCI DSS). Annual compliance is mandated by the payment card schemes and banks. Due to this there are certain requirements that need to be met when building a Payment Page. Refer to our Risk and Compliance guide to assist you through the payment page requirements and eDDR requirements.