Important Considerations

Wallet Initialised Charges Archival Process

To render 'wallet' buttons (PayPal, Apple Pay, Google Pay) a 'wallet initialised' charge is required to be created in PowerBoard (as per existing behaviour). This means that every time a user checking out clicks on an accordion option within the Master Widget that is for a wallet payment gateway type, it will generate a new wallet initialised charge.

As part of the Checkout feature, PowerBoard is performing treatment on such 'abandoned' wallet initialised charges. This means that for wallet initialised charges that do not make it to either 'completed' or 'failed', that PowerBoard will do the following:

• If an unexpected scenario occurs during the flow, resulting in a failed flow (ie. validation of charge status is not triggered) while the charge is in the 'wallet_initialized' status, the archiving process of this charge will occur immediately after the checkout process fails

• If the checkout session times out (15 minutes), any charge status remaining in 'wallet_initialized' status will be archived immediately after the time out

• In the following scenario:

  • PayPal accordion is clicked, and a wallet initialisation is generated.
  • Google Pay accordion is clicked, and another wallet initialisation is generated.
  • PayPal accordion is clicked again, generating a second wallet initialisation.
  • Finally, the card accordion is clicked, and the card is used for checkout.

  Three wallet initialisation charges (2 for PayPal and 1 for Google Pay) will be created and subsequently archived. The archiving process for every wallet charge with the 'wallet_initialized' status will occur immediately after another payment method is selected in the accordion.

📘

Note:

This is an asynchronous process, meaning the cardholder will not have to wait for this background archival process to complete in order to navigate the Master Widget and complete their purchase.

Additionally, merchants must be educated to ignore any 'wallet initialized' charges from any reconciliation or data analysis activities they may be performing.

Remove Payment Method Scenario - Sequence of Events

If you would like to remove payment methods from your checkout, please ensure you apply the following sequence when doing so:

1. Depending on the nature of your modifications, edit your existing configuration template ID or create a new configuration template ID

   a. If you create a new one, it will not apply on the front-end until you update the /intent API call to point to the new configuration template ID

   b. If you edit a configuration template that is already used in the existing /intent API request, it will apply on the front end as soon as you save the change

2. As an optional step, edit or remove any gateway_id's that are no longer in use

📘

Note:

Please ensure that the above sequence is strictly adhered to if removing payment options from your checkout

Production Considerations

Intent Token Expiry

• Each intent token is active for 15 minutes only
• Users must complete their payment within this timeframe
• Plan your checkout flow accordingly to minimise abandonment due to timeouts

Amount Changes

• If you modify the payment amount during checkout (e.g., applying coupon codes), you must regenerate the intent and reinitialise the widget
• This ensures payment integrity and prevents amount mismatches

Error Handling

• Always implement proper error handling for all widget events
• Provide clear user feedback for payment failures and expired sessions
• Consider implementing retry mechanisms for failed payments

Security

• Use domain whitelisting in your configuration templates for production environments
• Ensure your access tokens have only the necessary permissions
• Regularly review and update your security configurations