Of these the first 3 all use integration methods that paypal is somewhat working to phase out - with the latter Rest being the way they are going.
However, the REST gateway supports multiple different integrations. In particular it supports both the Paypal_Pro type methodology of taking credit card details onsite and the Paypal Express type methodology of having the user authenticate to paypal and pre-approve the amount, with it being post-approved.
I'm working on this latter type of Rest implementation. I'm guessing (but don't have the right account to confirm) that it may still be the case where both a paypal button and adding card details are supported on the same form - so the calling code may not be able to clearly differentiate the gateway.
I've been working on the assumption that the Rest gateway can and should figure out what sort of transaction it is processing & proceed on that basis - hence I have put up https://github.com/thephpleague/omnipay-paypal/pull/220
And I also have a patch I'm working with locally (which might get added to that) which allows the createCard function to work & create a re-usable token regardless of whether it is card present or Paypal-button-authorised.
A case could be made that the Paypal Express Rest should be a separate gateway. I'm currently leaning against that because I think it could be that the same form might present the button and fields for card details (like earlier paypal versions) so post-submit may be the right time to figure out which method is in play and also because I think there is already a bit of multiple-approach handling in the Rest api code.
Omnipay currently integrates 4 gateways -
PayPal_Express (PayPal Express Checkout) PayPal_ExpressInContext (PayPal Express In-Context Checkout) PayPal_Pro (PayPal Website Payments Pro) PayPal_Rest (Paypal Rest API)
Of these the first 3 all use integration methods that paypal is somewhat working to phase out - with the latter Rest being the way they are going.
However, the REST gateway supports multiple different integrations. In particular it supports both the Paypal_Pro type methodology of taking credit card details onsite and the Paypal Express type methodology of having the user authenticate to paypal and pre-approve the amount, with it being post-approved.
I'm working on this latter type of Rest implementation. I'm guessing (but don't have the right account to confirm) that it may still be the case where both a paypal button and adding card details are supported on the same form - so the calling code may not be able to clearly differentiate the gateway.
I've been working on the assumption that the Rest gateway can and should figure out what sort of transaction it is processing & proceed on that basis - hence I have put up https://github.com/thephpleague/omnipay-paypal/pull/220
And I also have a patch I'm working with locally (which might get added to that) which allows the createCard function to work & create a re-usable token regardless of whether it is card present or Paypal-button-authorised.
A case could be made that the Paypal Express Rest should be a separate gateway. I'm currently leaning against that because I think it could be that the same form might present the button and fields for card details (like earlier paypal versions) so post-submit may be the right time to figure out which method is in play and also because I think there is already a bit of multiple-approach handling in the Rest api code.