Payment Processing Design Considerations
An SHF Payment instance is the counterpart of a HIPS Order. Thus, the status changes of each will be in tandem.
In fact - other than the initial payment status (created) - payment status is identical to the corresponding order status that is visible to us.
The table below is based upon the use of the "Checkout API" integration with HIPS. One result of this is that we should not expect to see HIPS invoke the user_return_url_on_fail redirect, based on current HIPS processing (although this might change in the future).
| # | Current Status | Action | New Status |
|---|---|---|---|
| 1 | nil |
User clicks "Pay Membership Fee" link. A new Payment instance is created, and an order create request is issued to HIPS. | created |
| 2 | created |
HIPS create returns success status and the order. User is presented with the HIPS checkout form. |
pending |
| 3 | pending |
User successfully completes payment, HIPS redirects user to user_return_url_on_success. |
success |
| 4 | pending |
User does not complete payment (abandons checkout). | pending |
| 5 | pending |
User sees pending payment on their account page, clicks link to continue payment. This time, payment is successful - see step 3. |
success |
Note that we are not using any HIPS webhooks (webhook_url) to be notified of order status changes, since there is no need for that given the simple transition scheme above. That is, the "Checkout API" presents a simple interface to us that hides complexity (and other order status changes) that we don't need to be concerned with.
