Michael Dunstan <[email protected]> writes: > There *may* be a case for dynamically selecting from several different > on-site payment processors. Where the code picks one that matches the > currency of the shopper. If buying in USD then use ProcessorA or if > buying in GBP then use ProcessorB. (Though that'd be a bit more > elaborate than usual I suspect.)
Christopher Johnson <[email protected]> writes: > (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. Great scenarios! I hadn't thought of these. The lesson I take away from them is: there might be internal, site-related reasons to support different onsite processors; but there are probably no scenarios where the *user* will choose. Which means there need be no user-facing view for choosing among onsite payment processors. At the very least, the documentation I'll write up this week will outline, for prospective integrators, how to create, program, and register "MyOwnOnsiteProcessor" that looks at the currency or credit card or whatever, and then calls one of several back-end payment processors. In the future, if we wanted store owners to be able to make this kind of decision without hiring a programmer, we'd need to create an onsite payment processors whose site-configuration view let the store owner build, via a simple web GUI, the decision matrix that chooses the payment processor. That, however, would be a whole different project, and, happily, can be undertaken as separate work once the offsite refactoring is complete. -- Brandon Craig Rhodes [email protected] http://rhodesmill.org/brandon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
