Hey Brandon, I think you're on the right track. I don't see what difference it would make to a user if you are doing onsite processing of authorize.net, paymentech, etc.
It sounds like what you are doing is offering a choice between 1 or more offsite processors and/or an onsite processing option - is that it? If so, just to play out the future...we could potentially have a site with: - onsite option: authorize.net - offsite option: authorizet.net, google checkout, paypal. ie perhaps there is a user preference for offsite payment processing (personally, I think it will be years before there is a noticeable preference for that and/or awareness of PCI issues, but it's possible...). Just to throw out one other minor use case that could evoke desire for 2 onsite payment processors (not saying we need this, just brainstorming!). Say you are a site owner and you have credit card processing with authorize.net for Visa and MC, but you use Paymentech for AMEX because the fees are much lower (just making this up, but is feasible). So you would want someone checking out to end up processing based on their credit card. That is probably something that should just be done based on the credit card choice on checkout, as opposed to asking them to choose (and maybe naming the processors with the cc type to encourage proper choice:), but just wanted to throw it out there. One final suggestion, as you are studying and researching...it may be helpful to check out what Magento Commerce has done, as it is a fairly well developed solution (though about the same age as GetPaid). Best wishes, Chris On 8/29/09, Brandon Craig Rhodes <[email protected]> wrote: > > We have established that a store owner might want to allow the user to > choose between different off-site checkout processes, because the user > might have an account already on one but not on another. One user might > have a Google Checkout account already; another, a PayPal account. And, > so, a certain shop owner might want the user confronted during the > checkout process with a screen (which the "multiplepaymentprocessor" > guys already have an early working version of!) like: > > How would you like to check out? > > * Use Google Checkout > * Use PayPal > * Enter my credit card information right here on-site > > So, we need to support user choice between different off-site payment > processors, and also let them choose to remain on-site if that is an > option the store owner wants to offer. > > But what about the various on-site mechanisms? Take, for example, > AuthorizeDotNet and PayFlowPro: both of them let Plone accept the credit > card information, and then, hidden back behind Plone where the user > never even knows they're there, they authorize and charge the payment on > behalf of the site. > > Because they're hidden, and the user cannot interact with them directly > - they never get to talk to the user's browser or anything - it's not > clear to me that it would ever be useful to let the user choose among > these credit card processors. That is, I'm not sure there's a use case > for the user being presented with the following dialog: > > How would you like your credit card charged? > > * Use AuthorizeDotNet to check my credit card number > * Use PaymentTech to check my credit card number > > So, what do *you* guys think? > > Should we support multiple back-ends being active at once, with the user > choosing between them? Or should we - as I suspect we should - make > store owners choose only one back-end processor, if they want to support > on-site checkout, and never have the option of the user choosing? > > If so, then I think that might support my earlier contention for the > difference between "Checkout wizards" and "Payment processors". (Which > surprises me a little, as I have waffled back and forth this week on > whether it was really a good distinction.) The important difference > would be: you can have *several* checkout wizards active for a given > store (including the built-in GetPaid wizard), and let users select > between them; but you can have at most one "Payment processor", because > when the user reaches the final page of the on-site wizard and checks > "Purchase", there has to be just one choice for where GetPaid goes to > get that credit card number verified, with no further interaction or > help from the user. > > Am I on the right track here? Or is there some crazy reason that I'm > not thinking of to ever expose to users that "AuthorizeDotNet" and > "PayFlowPro" are both available to check their credit card number, so > that they have to choose? > > -- > Brandon Craig Rhodes [email protected] > http://rhodesmill.org/brandon > > > > -- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en -~----------~----~----~----~------~----~------~--~---
