Order status only one of three options

[darylp041]

As per the notes for both v2 and v3, SagePay only ever seems to return one of three states: STATUS_COMPLETED, STATUS_PENDING or, and the default, STATUS_FAILED.

We have an integration problem, where we are using the authorize() function and this always sends a DEFERRED payment. In some cases payments should/could be AUTHENTICATE. However, using the authorize() callback we're only ever going to get DEFERRED. A setTxType() would be ideal in side DirectGateway. Which, if using Authorize, you could override the default action.

Similarly, when payments are returned acceptNotification() will only ever return one of three states: STATUS_COMPLETED, STATUS_PENDING or, and the default, STATUS_FAILED. This was already raised here: #42

Therefore, each successful transaction that returns an AUTHENTICATED state technically fails, even though its not failed. My understanding of "$gateway->capture([...]);" is that it will release the funds immediately and stops using the acceptNotification(), which has been advised in issue #69.

[judgej]

Thanks. Sounds like some finer control is needed over the service types. I'll read up and summarise the state transitions that needs to be supported, to check that my understanding is correct. Ideally it would all fit into the Omnipay sequence, but have options that modifies that sequence (e.g. so authorize() and capture() perform the appropriate action depending on options used to define which model you have implemented, e.g. a deferred or an authenticated model).

Does that make sense?

[judgej]

The Notify handler (transaction asynchronous response for Server API) can receive any of these statuses:

• OK - a PAYMENT being authorised
• NOTAUTHED - TBC (not sure, but is this a failure to authorise an authenticated transaction, perhaps due to lack of funds by the time we get to trying to authorise the authentication, i.e. use the card details we previously captured in the transaction?)
• PENDING - transaction in limbo - will hear back later with the real result
• ABORT - transaction cancelled (manually or automatically) before it is settled
• REJECTED - a PAYMENT, DEFERRED or AUTHENTICATE failing CC validation or verification.
• AUTHENTICATED - card details grabbed in AUTHENTICATE transaction with 3D Secure
• REGISTERED - card details grabbed in AUTHENTICATE transaction without 3D Secure
• ERROR - TBC

An ABORT can happen:

• By a user canceling while entering CC details.
• By a VOID being sent before settlement the morning after a PAYMENT, AUTHORISE or RELEASE.
• A DEFERRED transaction unused for 30 days.
• An AUTHORISED transaction unused for 90 days (30 days for MC).

Omnipay has statuses:

• COMPLETED - (OK, AUTHENTICATED, REGISTERED)
• PENDING - (PENDING)
• FAILED - (ERROR, ABORT, NOTAUTHED, REJECTED)

Note that because an AUTHENTICATE can be captured (AUTHORISE) in multiple transaction up to the 115% mark, each transaction can go through its own ABORT before it is cleared the next day. A single transaction can branch out like this in quite a complicated way. A transaction can always be voided before it is cleared in the morning, so be aware an OK is not a final state for up to 24 hours. Once it has cleared, then it can no longer be voided, and would need to be refunded instead to cancel it.

[judgej]

The Direct API also needs to handle the response status. This API has all the same statuses as the Server API (via the notification handler) except PENDING, and in addition it has:

• 3DAUTH - a 3D-Secure redirect is needed
• PPREDIRECT - a PayPal redirect is needed
• MALFORMED - same as Server API transaction registration (invalid address, card, missing data etc.)
• INVALID - TBC

[judgej]

Release 3.1.0