| Issue 117: | Need to Persist processor_order_id and make visible in Orders search/listing page | |
| Back to list |
Sign in to add a comment
|
The best thing we can do to correlate PGP orders to Authorize.net (and other processors) order reports is to store the processor_order_id (defined in interfaces.py within the IOrder, but never persisted as far as I can tell.) We could go as far as setting the PGP order_id to be the processor_order_id. What would the harm be? I can only see good things from that, as it'd make for cross-referencing PGP orders to Authorize.net orders very simple. Whether the processor_order_id is the same order_id used by PGP or an additional stored field, it should be a very key piece of info on the order record shown by the Orders listing page and detail page. |
||||||||||
,
Sep 25, 2007
I haven't addressed this yet, but I have updated lib/getpaid/authorizenet/authorizenet.py, so that the Invoice Number field in the Order Details section on the Authorize.net reports pages reflects the PloneGetPaid order#. We need the same type of cross-reference ability from the PGP side, though. |
|||||||||||
,
Oct 03, 2008
Apparently Paymentech expects the order id, so it already uses the same order id. This needs to be looked at for authnet in particular.
Labels: -Priority-Critical Priority-High Component-Pay-processors
|
|||||||||||
,
Oct 12, 2008
If the per-processor's package has its authorize() method updated with one line of code (use the nullpayment test process's authorize() as an example) to populate the getpaid order trans_id, that trans_id will appear in the GetPaid admin Orders (tab) listing page.
Status: Started
|
|||||||||||
 Sign in to add a comment
|
|||||||||||
