Closed jagarza closed 9 years ago
The access token that is returned by the future payment consent is only usable for that single payment. It is not a replacement or an update to the default access token. For using the future payment consented access token, you would have to manually pass that in, into the payment.
However, I think it would be nice to test this out, as I am not sure what happens when you do two consecutive payments using the access token. I will dig further into this, and respond you back soon.
Well, my point is that , when cache is active, the SDK is taking the OLD access token and NOT the new one just created with the refresh_token. Therefore the FuturePayment is not executed. It does not fail, but instead of generating the FuturePayment, it CREATEs the payment and gives you the link to the user's approval as I wrote.
What I did was
$payment->updateAccessToken($refreshToken, $apiContext);
Which suposse to update the Access Token by using the RefreshToken I am passing.
As I said, all works fine if CACHE is OFF
That makes sense. I think adding that forceful update trigger on updateAccessToken method would do the trick.
I found a problem using the SDK as it is. If you install the SDK, it comes with the cache flag ON. If you use the Obtain User's Consent with the standard SCOPE, but then you add, say Future Payments to the scope, the subsequent calls will use the original access_token (which not includes the latest change).
In other words, it looks like the cache does not update the access_token with the latest call. I think that it should update the auth.cache with the latest call, if value changes, otherwise It cannot be called cache.
Example::
[29-06-2015 04:10:28] PayPal\Core\PayPalHttpConnection: DEBUG : Request Data : grant_type=refresh_token&refresh_token=YKxwWkZ1-_MTCx93JBRf5cABHlfLmQQrv7-ZpGvR7MY7YaTa7LS0PBUCwSobrTF4SHz7wd8BlsLPW_taE0-2Ntwr4ruO6bwiu9htkwXqUBsWNd-3RyOZfDEEnqk [29-06-2015 04:10:28] PayPal\Core\PayPalHttpConnection: DEBUG : Response Data : {"scope":"phone address email https://uri.paypal.com/services/payments/futurepayments openid profile https://api.paypal.com/v1/payments/.*","access_token":"A015TqSRtzr0nnwUsCFKgfW58qBkRFz0EyIfYpm5MuTQ9w0","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":900}
[29-06-2015 04:10:28] PayPal\Core\PayPalHttpConnection: INFO : POST https://api.sandbox.paypal.com/v1/payments/payment [29-06-2015 04:10:28] PayPal\Core\PayPalHttpConnection: INFO : Invalid or no certificate authority found - Retrying using bundled CA certs file [29-06-2015 04:10:30] PayPal\Core\PayPalHttpConnection: DEBUG : Request Headers : POST /v1/payments/payment HTTP/1.1, Host: api.sandbox.paypal.com, Accept: /, Content-Type: application/json, User-Agent: PayPalSDK/PayPal-PHP-SDK 1.4.0 (lang=PHP;v=5.3.28;bit=32;os=Darwin_13.4.0;machine=x86_64;openssl=1.0.1g;curl=7.35.0), Authorization: Bearer A015rTCpp88OdH-otF4pCc.6QI0OmEAyIM8srokKrRvJ2co, PayPal-Request-Id: 4503143557622618834, Content-Length: 354, ,
....... You can see that the access_token taken in the next call is A015rTCpp88OdH-otF4pCc.6QI0OmEAyIM8srokKrRvJ2co
and not the one that comes from the FuturePayment refresh_token: A015TqSRtzr0nnwUsCFKgfW58qBkRFz0EyIfYpm5MuTQ9w0
So the response is not really doing the FuturePayment, and just generating a general payment with the approval API (payment not executed as it should)
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-3K1504810J390290A
If I deactivate the cache and run it again, it will work. ....... Conclusion: something is failing in the implementation of the cache... or I am missing something.
Thanks.