When a user selects to buy points on your website, they are either redirected to a payment processors website or we need to collect details from them to capture a payment e.g. credit card details.
This is done on a dynamically generated “Checkout” page. This page is generated on the same URL where a shortcode is used and is force loaded before your theme gets a chance to render the page. This means that there is no direct checkout URL that users can visit directly.
In order for the checkout page to trigger, a user must provide the payment gateway they want to use for payment, the amount of points they want to buy and if you sell more than one type of points, the point type they want to purchase. This along with a security token will trigger the checkout page.
Once the checkout page has been triggered, the first thing that occurs before the users sees the page is that their request is saved as a “Pending Payment”. This is so if a transaction can not be completed, a user can make a new attempt again later. Once a pending payment has been paid, it is deleted.
The checkout page can do two things: Redirect the buyer to the payment processor (remote gateway) or present a payment form in order to capture details needed for payment e.g. credit card details (local gateway). Some gateways however do not use the checkout page, e.g. the Stripe gateway uses it’s own checkout window.
A rewrite is planned of the checkout page with myCRED 1.8. This will shift to using a popup modal window for purchases instead of a fully rendered page.
