php - Paypal AngellEye DoExpressCheckout - data mismatch
I am just starting to use the AngellEye library with php, in particular the SetExpressCheckout which calls DoExpressCheckoutPayment.
I have built my cart and posted to Paypal using the SetExpressCheckout functionality.
All appears to go through properly, but I had left the DoExpressCheckoutPayment as it was with the original basket as in the demo. It is this basket which goes through to Paypal, not my basket.
Is this correct? I thought it would have noticed the original basket is not what is being finally processed and thrown an error. I know I can rebuild the basket in DoExpressCheckoutPayment, but I thought they should match to catch any interfering which might have taken place between my site and Paypal - or is that my job to check? (Fine if it is!)
Incidentally, it did throw an error when the currency code's did not match - I had to change them both to GBP
If I have misunderstood how it should work, my apologies.
Answer
Solution:
In general practice:
The contents and values in SetExpressCheckout need to match DoExpressCheckoutPayment within the allowed realm (you are allowed to change the values and items of the purchase on a user... within reason).
Why it maybe didn't complain:
The reason it probably didn't completely complain, is the difference between the 'demo data' and 'actual' was within the allowed for a seller to change. And it simply accepted the differences for the final transaction (except as you noted, currency code cannot change!).
See, when you initially send a user to paypal with information such as:
Then that user 'agrees to those conditions and authorizes the transaction'. You get the authorization code to continue with the capture. However it is at this point the seller has a margin for change (although not recommended as you easily upset customers). Where you could do a final transaction of:
Although thats still 'acceptable' for the PayPal system... it may not be proper customer business.
Concern on interference:
Your concern for "interfering which might have taken place" should not be one. The transaction code, the merchant id, and secret are all used to prevent that kind of middle-man-meddling. And since the Set and Do actions are both server-side (not javascript), the user could not alter those values directly themselves to get a different product for a lower price.
Hope that helps clarify your concerns/questions.