Need to Persist processor_order_id and make visible in Orders search/listing page

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by ctxl...@gmail.com on 21 Sep 2007 at 10:18

[GoogleCodeExporter]

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.

Original comment by ctxl...@gmail.com on 25 Sep 2007 at 4:24

[GoogleCodeExporter]

Apparently Paymentech expects the order id, so it already uses the same order 
id.
This needs to be looked at for authnet in particular. 

Original comment by cjj.ifpe...@gmail.com on 3 Oct 2008 at 2:42

• Added labels: Component-Pay-processors, Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

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.

Original comment by ctxl...@gmail.com on 12 Oct 2008 at 4:24

• Changed state: Started