This article speaks to the requirements needed in order to present Capitec Pay as a payment method on checkout, depending on whether your business model is classified as High Risk or Low Risk.
The crux of the requirement rests on whether a merchant needs to populate a 'customer.idNumber' parameter in their POST request. High-Risk Merchants are required to send the verified ID number of their customer in API requests (customers should not be able to edit this value).
The summary is as follows:
High-Risk merchants:
- If no customer.idNumber is passed, Capitec Pay does not show on Checkout
- If customer.idNumber is passed, Capitec Pay is available
Low-Risk merchants:
- Regardless of if customer.idNumber is passed, Capitec Pay will be available.
SB-Tech merchants:
- SB-tech does not support the customer.idNumber
Plugins/Integrations:
- Plugins don't support customer.idNumber
1. Checkout: High-risk Merchants:
- If no customer.idNumber is passed, Capitec Pay does not show on Checkout
- If customer.idNumber is passed, Capitec Pay is available.
- Merchants don't have the option to pay using phone numbers
2. Checkout: Low-risk Merchants:
- Regardless of if customer.idNumber is passed, Capitec Pay will be available.
- Merchants see the option to pay using phone numbers
3. Checkout: SB-Tech Merchants:
Note: SB-tech is a betting software
- Merchant using SB-tech are classified by Capitec Pay as high risk merchants
- SB-tech doesn't send the customer.idNumber parameter in the requests to checkout
- Merchants using SB-tech won't be able to pay using Capitec Pay, since the option won't be visible on checkout.
4. Checkout: Plugins/Integrations:
If merchant is high risk and using any of the below plugins/integration, they cannot pass through the customer.idNumber parameter to us hence they won't see Capitec Pay as an option on checkout;
- Payment links
- Xero
- All plugins: Shopify, Wix, Magento, WooCommerce, NopCommerce, OpenCart, Ecwid etc.