[bop-devel] MasterCard/Discover Partial Authorization

[Jason Hall]

I recently added similar support into the Litle Plugin.  It works, but
I was kinda making up api along the way, and would be willing to adopt
whatever we decide is a standard.

http://github.com/Jayceh/Business--OnlinePayment--Litle



On Wed, Oct 27, 2010 at 10:45 AM, Shane Corgatelli <shane at eznettools.com> wrote:
> Has any one given any thought to implementing the new Partial
> Authorization/Balance Response requirements. We currently use an
> in-house solution for communicating with AuthorizeNet, but are looking
> at adopting BOP if it will support partial authorizations.
>
> I am willing to work on adding support to BOP and the AuthorizeNet
> back-end, but I wanted to see if anyone else is working on it already.
> If not I want to start the discussion on the best way to do this.
>
> I'm not sure how other processors will handle this, but from what I have
> read so far, AuthorizeNet and PayPal will handle this completely
> differently.
>
> It appears that for PayPal there is no further actions required for a
> partial auth. However the AuthorizeNet AIM docs state that "All
> transactions are put in a hold state until the final transaction is
> received. This is the transaction with a splitTenderId where the
> remaining amount is approved."
>
> According to my understanding, under AuthorizeNet, you have to use the
> x_split_tender_id field instead of the x_trans_id when working with
> partial auth transactions. Under the AuthorizeNet back-end order_number
> is always mapped to x_trans_id.
>
> Some initial thoughts on API changes to BOP:
>
> Perhaps the submit method should return a "Result" object:
>  * This would reflect the status of the transaction. It would implement
>    all of the Transaction Result Methods of BOP (these would still be
>    available as well for the BOP instance).
>  * It can be passed back to submit() for void and other transactions
>    in place of order_number.
>  * There would be a base result class that most back-ends could use
>    as-is, but each back-end could extend the base result class if
>    needed. All of the result classes would, of course, have to conform
>    to a minimum API.
>    * For example, the AuthorizeNet back-end would add a split_tender_id
>      field that it would use instead of the order_number if present.
>  * It may need some sort of serialization so it could be saved and
>    restored between web requests (at least the
>    order_number/split_tender_id).
>
> New Transaction Result Methods:
> is_partial()      - returns true for partial approval/authorization
> balance_amount()  - returns the balance on card after approval (partial
>                    or otherwise), undef if not available.
> approved_amount() - always returns the approved amount. If not partial,
>                    equals the 'amount' transaction field
>
> These would be available both under BOP like the current methods, and
> also under the result object.
>
> I'm not sure what the right thing for is_success() to do. I'm thinking
> that it should return false in the case of a partial auth since there
> may be further actions that may be required.
>
> Any thoughts?
>
> Thanks
> --
> Shane Corgatelli
>
> Programming Manager
> EZ-NetTools
> http://www.eznettools.net/
>
> _______________________________________________
> bop-devel mailing list
> bop-devel at 420.am
> http://420.am/cgi-bin/mailman/listinfo/bop-devel
>



-- 
Jayce^

The Cloud is my Platform
ΜΟΛΩΝ ΛΑΒΕ