Added new payment request for deferred payments

[jrattue]

It is currently not possible to create a new Sage pay transaction of any type other then PAYMENT when using server integration, this adds the functionality for DEFERRED payments.

[jrattue]

@judgej can you review this PR?

[judgej]

Quick question: is a deferred purchase request any different to an authorise request? If not, then the ServerDeferredPurchaseRequest is already covered by the ServerAuthorizeRequest. They look the same to me (in the code at least), but I may be missing something.

The CaptureRequest is then used to capture what has been authorised (aka DEFERRED).

This is a serious question, because I realise there are two different ways of deferring payment in Sage Pay, each involving different ways of collecting (e.g. one must be collected in full just once, and the other can be an open authorisation that can have multiple amounts up to a limit be collected over a longer period of time). TBH, I'm not fully up to speed on those features, which can be hard to follow through the docs.

[judgej]

Okay, looked the docs and the code.

At the moment, this gateway driver implements Authorize requests using the DEFERRED payment type. So on the face of it, the payment type your PR implements is already supported.

A bit of background on the payment types that Sage Pay supports:

• PAYMENT - register, authorise and settle the transaction in one go.
• DEFERRED - register and authorise the payment, but settle it (RELEASE aka Capture) at a later date, within 30 days (ideally stick closer to 6 days). Until released or aborted, this leaves a shadow (a kind of reserved amount the card owner can't spend elsewhere) on the card account.
• AUTHENTICATE - authenticate the card and user details, but do not authorise payment with the bank. These details are held for 90 days (with some exceptions) and can be authorised later without the user needing to be present again. The result is not determined by funds available; that is done later. This leaves no shadow on the card account.
• AUTHORISE - authorise a payment against a previously authenticated card. Value can be up to 115% of the authenticated amount. User does not need to be present. Whether the authorisation is successful, will depend on funds available at this time.

Use PAYMENT and DEFERRED in most instances (both supported by OmniPay). Use AUTHENTICATE+AUTHORISE if the final amount is not fully known up front, or authorisation or release cannot normally be done within a reasonable time (6 days usually, or 30 days absolute max).

[judgej]

Conclusion: OmniPay already supports DEFERRED payments, and this PR is not needed. But please kick me if I've misunderstood the whole thing.

[jrattue]

Thanks for looking into this and doing alot of reading/research.

The reason I created this, is that when using the ServerPurchaseRequest the action is already set to PAYMENT this meant that the payment was taken straight away and not DEFERRED. I created the new ServerDeferredPurchaseRequest to allow DEFERRED payments to be created.

Using the existing ServerPurchaseRequest how would you create a DEFERRED payment?

[judgej]

ServerPurchaseRequest is to take a payment. If you just want to authorise and take the payment later, then the ServerAuthorizeRequest and CaptureRequest messages serve that purpose.

In order words, don't use ServerPurchaseRequest if you don't want to make a purchase request.

[judgej]

$gateway = OmniPay::create('SagePay\Server');
...
// Use "authorize" here and not "purchase"
$requestMessage = $gateway->authorize([...]);

$responseMessage = $requestMessage->send();

Then later:

$gateway = OmniPay::create('SagePay\Server');
...
$requestMessage = $gateway->capture([...]);

$responseMessage = $requestMessage->send();

[jrattue]

I see, feel free to close this PR as is no longer needed.

[judgej]

Will do, thanks. Let us know how it goes, switching over from your branch.