Skip Menu |

This queue is for tickets about the Business-OnlinePayment-eSelectPlus CPAN distribution.

Report information
The Basics
Id: 71171
Status: resolved
Priority: 0/
Queue: Business-OnlinePayment-eSelectPlus

People
Owner: Nobody in particular
Requestors: DONOR [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.03
Fixed in: 0.06



Subject: Pre-authorization & Capture/completion
We have enhanced Business::OnlinePayment::eSelectPlus for pre-authorization & capture/completion. We hope this enhancement can be incorporated or adapted for BOP::eSelectPlus on CPAN. 0.05 2011-09-20 - Pre-auth & capture/completion are now supported. Backwards-compatibility note: callers who specify the order_id, should now specify it with 'order_id' in content (not 'order_number', which is now used for eSelectPlus txn_number, for capture). Note: the order_number() method now returns the 'TransID' (not 'ReferenceNum') response field from eSelectPlus. Note: testing preauth seems to work only with test store #1 (CAD). - by Randall Whitman <www.whizman.com> on contract to DonorWare LLC dba donor.com <cpan @ donor . com>. Developer believes the following entry is incorrect in Moneris documentation eSELECTplus_Perl_IG Appendix B. Definitions of Response Fields (in both US/CA): Txn_number Per testing, there is never a "Txn_number" response element present, but rather "TransID". Also, in mpgClasses.pl (the gateway-interaction code on which the doc examples are based), the getTxnNumber() method gets the value from the TransID element in the response. The eSelectPlus order_id required parameter, can either be passed by the caller to B:OP, or generated within B:OP eSelectPlus. Examples respectively: t/capture_ca.t & t/capture_us.t . As of version 0.05, the content method now uses a gateway-specific 'order_id' (not 'order_num') parameter for caller-specified eSelectPlus order_id, and the 'order_number' parameter is now used as the transaction number (eSelectPlus txn_number, from TransID) for Post Authorization (completion/capture). Also for Post Authorization, the 'order_id' parameter must match the order_id used for the corresponding Authorization Only (pre-authorization). Existing (0.03): - pre-auth & capture/completion not supported - for purchase/normal-sale, the eSelectPlus order_id required parameter, could be passed in as content{order-number}, else was generated inside B:OP eSelectPlus (generate_order_id). (eSelectPlus ReceiptId response, same value as order_id, not returned by any B:OP accessor.) - eSelectPlus ReferenceNum response, returned by B:OP order_number(). - eSelectPlus TransID response, missing from Moneris eSelectPlus docs (cf Txn_number - which in fact is never present in the response), not returned by any B:OP accessor. New: - pre-auth/capture is supported - for pre-auth as well as for purchase/normal-sale, the eSelectPlus order_id required parameter, can be passed in as content{order_id}, else is generated inside B:OP eSelectPlus (generate_order_id). eSelectPlus ReceiptId response, equivalent to passed-in/generated order_id, returned by gateway-specific B:OP accessor order_id(). - eSelectPlus ReferenceNum response, not returned by any B:OP accessor. - eSelectPlus TransID response, which is returned by standard B:OP accessor order_number(), is the value needed for capture/completion, as B:OP content{order_number}, which is mapped to eSelectPlus txn_number. (See t/capture*.t for sample.) Alternate (not implemented): - map content{order-number} to order-id, as done in B:OP eSelectPlus 0.03, so that would be done for capture/pre-auth as well as purchase. - pass the B:OP order_number() [eSelectPlus TransID] (not BOP authorization()) from pre-auth, as content{authorization} [map to eSelectPlus txn_number] (not content{order_number}. ~ various other permutations of method and content-key nomenclature. ==== Gateway Pre-auth (or sale) Component Capture/void - B:OP response B:OP accessor originating %content{order_number} AuthorizeNet: Response index BOP return/method Origin/desc Use for capture/void 5 authorization approval code no 7 order_number gateway xn id yes: x_Trans_ID PayflowPro: Response key BOP return/method Origin/desc Use for capture/void AUTHCODE authorization auth code no PNREF order_number yes: ORIGID EXact <https://rt.cpan.org/Public/Bug/Display.html?id=70658>: Response tag BOP return/method Origin/desc Use for capture/void Authorization_Num authorization bank auth # Yes!: Authorization_Num SequenceNo order_number gateway xn id no eSelectPlus (new/0.05): Response tag BOP return/method Origin/desc Use for capture/void AuthCode authorization auth code no TransID order_number gateway Txn yes: txn_number ReferenceNum usused (no accessor) gateway refnum not usable ReceiptId order_id content{order_id}| also: order_id generate_order_id (n.b. additional gateway-specific order_id, to originate in B:OP or caller) (existing eSelectPlus 0.03): Response tag BOP return/method Origin/desc No capture AuthCode authorization auth code not usable TransID unused (not in doc) gateway Txn not supported ReferenceNum order_number gateway refnum not usable ReceiptId none (no accessor) content{order_number}| needed generate_order_id (n.b. additional gateway-specific order_id, to originate in B:OP or caller) ==== The eSelectPlus test server seems to go down intermittently. When the eSelectPlus test server is up, the B:OP eSelectPlus tests pass. Attached Business-OnlinePayment-eSelectPlus-0.05.tar.gz contains the new test scripts for pre-auth & capture, but also contains customizations (internally numbered 0.04). Attached preauth-capture.patch.gz contains only changes made for pre-auth & capture, and only changed files, not the new ones. % sha1sum Business-OnlinePayment-eSelectPlus-0.05.tar.gz 01a8d8659242f82d412dba319526f69b95173c28 Business-OnlinePayment-eSelectPlus-0.05.tar.gz % gzip preauth-capture.patch % md5sum Business-OnlinePayment-eSelectPlus-0.05.tar.gz preauth-capture.patch.gz fc2d941130751da32dd5021428ac381d Business-OnlinePayment-eSelectPlus-0.05.tar.gz 101c8812bdbe8170cd59cd4fc127ef88 preauth-capture.patch.gz
Subject: preauth-capture.patch.gz
Download preauth-capture.patch.gz
application/x-gzip 3k

Message body not shown because it is not plain text.

Subject: Business-OnlinePayment-eSelectPlus-0.05.tar.gz

Message body not shown because it is not plain text.

Regarding "order_id": It is not acceptable to use gateway-specific fields for pre-auth data that needs to be sent for capture. This would require folks using different gateways to write different code to use them, which very much defeats the point of Business::OnlinePayment. From the end of "notes_for_module_writers_v3" in Business::OnlinePayment: Gateways will return one or two values from Authorization Only and Normal Authorization transactions that must be submitted back with a Post Authorization, Void, or Credit transaction. If the gateway returns one value, return this as "authorization" If the gateway returns two values, return one as "authorization" and the other as "order_number". Typically "authorization" is the more low-level value returned from the underlying processing network while "order_number" is a unique tranaction id generated by the gateway. Finally, if possible, send your changes as a unified diff (or multiple diffs for different changes) rather than as a tarball of your new proposed version.
Thanks for the pointer to the notes_for_module_writers_v3 additions newer than the version of B:OP that we have deployed. We are working on a couple other alternatives for Pre- and Post-Auth with Moneris eSelectPlus.
From: bitcard [...] whizman.com
<notes_for_module_writers_v3> If the gateway returns one value, return this as "authorization" If the gateway returns two values, return one as "authorization" and the other as "order_number". Typically "authorization" is the more low-level value returned from the underlying processing network while "order_number" is a unique tranaction id generated by the gateway. </notes_for_module_writers_v3> So, the typical pattern, applied to Moneris eSelectPlus, would be: Moneris-eSelectPlus key BOP key/accessor origin/description AuthCode authorization bank authorization code TransID/txn_number order_number gateway transaction number Issue being, for capture, instead of 2 fields from bank & gateway, the 2 fields required for Moneris eSelectPlus, originate at gateway & *client-side*. Moneris-eSelectPlus origin/description AuthCode bank authorization code (not used for capture) TransID/txn_number gateway transaction number (required for capture) ReceiptID/order_id client-side (required for capture) The approach toward which eSelectPlus.pm 0.01 was leaning, was to discard the AuthCode response [1]: AuthCode >>> [discard] TransID >>> authorization() >>> content{authorization} >>> txn_number ReceiptId >>> order_number() >>> content{order_number} >>> order_id In the scenario of the 2011/09 development work, customer stored the eSelectPlus AuthCode for reference or audit purposes. The approach of discarding the eSelectPlus AuthCode response, would conflict with a customer requirement to store the bank authorization code. (3 pigeons in 2 holes) [1] attached (tests pass when the test server is up) 741ddcf6dd72147992b6125ab3006a1d eSelectPlus-diff-0.03-0.06.gz c1015449f1ac7b3b48a601c7beb5f46c eSelectPlus-new-0.03-0.06.tar.gz
Subject: eSelectPlus-new-0.03-0.06.tar.gz

Message body not shown because it is not plain text.

Subject: eSelectPlus-diff-0.03-0.06.gz
Download eSelectPlus-diff-0.03-0.06.gz
application/x-gzip 2.5k

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #71171] Pre-authorization & Capture/completion
Date: Sat, 10 Nov 2012 13:49:08 -0800
To: Randall Whitman via RT <bug-Business-OnlinePayment-eSelectPlus [...] rt.cpan.org>
From: Ivan Kohler <ivan [...] freeside.biz>
On Tue, Oct 30, 2012 at 01:13:53PM -0400, Randall Whitman via RT wrote: Show quoted text
> > <notes_for_module_writers_v3> > If the gateway returns one value, return this as "authorization" > If the gateway returns two values, return one as "authorization" and the > other as "order_number". Typically "authorization" is the more low-level > value returned from the underlying processing network while "order_number" > is a unique tranaction id generated by the gateway. > </notes_for_module_writers_v3> > > So, the typical pattern, applied to Moneris eSelectPlus, would be: > > Moneris-eSelectPlus key BOP key/accessor origin/description > AuthCode authorization bank authorization code > TransID/txn_number order_number gateway transaction number > > Issue being, for capture, instead of 2 fields from bank & gateway, > the 2 fields required for Moneris eSelectPlus, originate at gateway & > *client-side*.
Yes, I guess the implied followup to the "Typically..." sentence from the notes above is that most improtant thing is functionality: that authorization and order_number are the two fields that the module user is expected to store and provide for follow-up transactions (capture/void/etc.). Show quoted text
> Moneris-eSelectPlus origin/description > AuthCode bank authorization code (not used for capture) > TransID/txn_number gateway transaction number (required for capture) > ReceiptID/order_id client-side (required for capture) > > The approach toward which eSelectPlus.pm 0.01 was leaning, was to discard > the AuthCode response [1]: > > AuthCode >>> [discard]
I think we should return this as result_code() or a new field of its own instead of discarding it. Show quoted text
> TransID >>> authorization() >>> content{authorization} >>> txn_number > ReceiptId >>> order_number() >>> content{order_number} >>> order_id
I think this works for me. What about Voids/Credits? Are the same two fields required? -- _ivan
These changes have been incorproated in our git. https://www.freeside.biz/gitweb/?p=Business-OnlinePayment-eSelectPlus.git;a=snapshot;h=HEAD;sf=tgz We are testing them now; if everything goes well, they will be included in a 0.05 release. It might still be useful to map AuthCode somewhere retrievable, but not of huge importance. Thanks!