a usability question

[Brandon Craig Rhodes]

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   brandon@...   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 getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christopher Johnson-7]

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 <brandon@...> 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   brandon@...
> 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 getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Michael Dunstan]

On Sun, Aug 30, 2009 at 4:21 AM, Brandon Craig
Rhodes<brandon@...> 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?

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.)

--
Michael Dunstan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Michael Dunstan]

On Mon, Aug 31, 2009 at 3:38 PM, Christopher
Johnson<cjj.ifpeople@...> wrote:
>
> ...we could potentially have a site with:
>
> - onsite option: authorize.net
> - offsite option: authorizet.net, google checkout, paypal.

This language of "onsite" and "offsite" seems to be much easier than
external/internal or async/sync.

--
Michael Dunstan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Brandon Craig Rhodes]

Michael Dunstan <michael.dunstan@...> 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 <cjj.ifpeople@...> 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   brandon@...   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 getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Brandon Craig Rhodes]

Michael Dunstan <michael.dunstan@...> writes:

> This language of "onsite" and "offsite" seems to be much easier than
> external/internal or async/sync.

And, also much easier than my own language of "checkout wizard/payment
processor".  Unless anyone has objects, I'll stick with the
onsite/offsite language from now on in the documentation and code that I
generate.

--
Brandon Craig Rhodes   brandon@...   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 getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christopher Johnson-7]

Michael - good point on the currency situation! Thanks for bringing that into the scenarios also.

-c

On Mon, Aug 31, 2009 at 5:16 AM, Michael Dunstan <michael.dunstan@...> wrote:

On Sun, Aug 30, 2009 at 4:21 AM, Brandon Craig
Rhodes<brandon@...> 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?

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.)

--
Michael Dunstan

--
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 getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---