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 payment statuses nil and 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 order create fails (HTTP code not 200, 201 or 202). Payment instance is deleted. | nil |
| 3 | created |
HIPS order create returns success status and the order. User is then presented with the HIPS checkout form. |
pending |
| 4 | pending |
User successfully completes payment, HIPS redirects user to user_return_url_on_success. |
success |
| 5 | pending |
User does not complete payment (abandons checkout). | pending |
| 6 | pending |
User sees pending payment on their account page, clicks link to continue payment. This time, payment is successful - see item 4. |
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.
