Use case: we need to be able to ship something in the return url that we can use to differentiate between Paypal Legacy and Express Checkout in the listener. We need this to not explode everything that pays attention to order_id. That is going to require some subtasks.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T87621 [epic] PayPal upgrade | |||
| Resolved | XenoRyet | T131816 Paypal Express checkout 1 hour test | |||
| Open | None | T138013 Epic: Distinguish PayPal legacy vs. Express Checkout transactions | |||
| Resolved | awight | T134605 Update audit parser for PayPal Express Checkout | |||
| Resolved | XenoRyet | T130851 Make PayPal listener understand Express Checkout | |||
| Resolved | • cwdent | T141654 Move legacy PayPal listener to SmashPig | |||
| Resolved | Ejegg | T134446 [Epic] Support Express Checkout recurring donations | |||
| Resolved | XenoRyet | T153720 PayPal EC response processor needs to act on "recurring" flag |
Event Timeline
Comment Actions
@Ppena
The biggest question mark here is actually for you. It seems that the easiest way to implement Express Checkout is as an entirely new gateway. This means that CiviCRM transaction IDs would look like "PAYPAL_EC 01234..." and the totals would be grouped separately from legacy transactions in various reports. Does this ring any alarm bells for you, or should I go ahead with that plan?
It makes me uncomfortable that the payments will all be going to the same PP account but will reconcile separately.
Comment Actions
Change 325818 had a related patch set uploaded (by Awight):
[WIP] Change gateway for Express Checkout