[bop-devel] Hosted Payment

[Stefan Hornburg (Racke)]

On 07/23/2014 08:05 PM, Angus Rogerson wrote:
> 
> On 2014-07-21, at 6:42 AM, Ivan Kohler wrote:
>>
>> It would also be worth discussing how the whole Verified by Visa / 
>> 3DSecure thing fits in.  So far we've only considered the "purely 
>> hosted"-type systems.  As I understand it, Verified by Visa / 3DSecure 
>> optionally adds a browser redirect (iframe?) type step to a transaction 
>> that starts as a regular B:OP merchant account-type transaction.  This 
>> seems somewhat different than the hosted/redirect type systems.
> 
> 
> I don't think the VbyV needs to look too different to the application. If the hosted payment module (whatever it is, or is called) can be sufficiently generic then the Verified by Visa and other features can happen without the application needing to understand what is going on.
> 
> 
> From the application, hosted and VbV/3DS should be able to look similar:
> - application optionally collects and sends credit card information to B:OP
> - B:OP does whatever it needs to do
> 	- application does not care what but B:OP:Gateway could be
> 		- http talking to the gateway requesting and confirming a nonVbV/3DS transaction
> 		- http talking to the gateway requesting a transaction which turns out to be VbV, and requires a redirect
> 		- just translating field names and building a bounce url for fully hosted sites
> - application asks B:OP what happened,
> 	- B:OP:Gateway returns either success or failure or redirect
> - and the application decides what to do
> 	- case: success - tell B:OP to finalize the transaction (which may or may not mean ACKing the transaction in some way)
> 	- case: failure - tell the user to try something else
> 	- case: redirect - whatever it has to do to redirect user
> 
> LOOP:
> 
> - the user's browser completes the missing parts of the transaction:
> 	- VbV/3DS
> 	- the whole collection of credit card number etc
> - the user's browser returns to a bounce back url in the application
> 
> - bounce back url in the application does something similar to above
> - application asks what happened,
> 	- B:OP:Gateway returns either success or failure or redirect
> 		- redirect (again) not likely, but why not keep it general
> - and the application decides what to do (as above)
> 	- case: success - tell B:OP to finalize the transaction (which may or may not mean ACKing the transaction in some way)
> 	- case: failure - tell the user to try something else
> 	- case: redirect - whatever it has to do to redirect user - and repeat LOOP
> 
> 
> An old school processor would never return more interaction needed and the user just falls out of the loop
> An old school processor which supports VbV would say interaction was needed, and would either fall out of the loop as above, or request more interaction with user and send them to an iframe or hosted page
> A purely hosted processor would require more interaction once then return to the application.
> Other sequences not yet invented, or not known to me, could involve multiple redirections - perhaps a credit card, paypal, VbyV combo of some sort - hmm, maybe a university student payment card which requires authentication to the university's system first, then a payment transaction against the card.
> 
> Just my thoughts, presented to get a conversation going ...
> 

Also, new gateways I'm working on (Ipayment / FirstData) require you to setup a HTML form in a specific
way - it would be good to add such a support as well. Not necessarily generate the HTML which I think
is a bad idea, but provide form action and form fields.

Regards
	Racke

-- 
Perl and Dancer Development

Visit our Perl::Dancer conference 2014:

http://act.perl.dance/