rubyonrailsin

Ajay,

Just woke up, hopped on here, and saw your response, Ill go through it
and make of it what I can,

Thankyou very much, appreciate it!

Cameron

On Mar 16, 8:10 am, Ajay CB <ajay...@gmail.com> wrote:
> Hi,
>
> I am half way through the implementation. There are many rough edges
> that I am still working out.
>
> Before I outline the solution here are the problems with hosted
> gateways
> (Hopefully it will help when someone else wants to take a shot at it)
>
> It relies on heavily browser redirects - this may not seem to be a
> problem at first, but it is a PITA.
> Once the amount + other details are passed on to the Payment Gateway
> via a form post, the possible outcomes are as follows:
> a) Happy flow - the customer selects the payment instrument and makes
> the payment, Once done he is redirected back to the registered
> callback URL.
> Process the payment as success and life goes on. no problems.
> b) Unsuccessful flow - Customer makes a bad payment, eg. expired card
> and such, he is redirected back with failure as the status - Do not
> record the payment on the order - keep the checkout alive, report the
> error and ask the customer to retry
> c) Broken flow - (a) or (b) happens and the last redirect does not
> happen because of a system failure - say network issue/etc. Now, we do
> not know if the payment was successful or not. This is a stuck order
> and needs to be cleared on a regular basis.
> The problem gets worse if the payment succeeds and the customer makes
> another payment (as the cart/checkout is still alive) thinking it
> failed. Now we have 2 payments for the same order.
> One more ugly case is: the customer changes the cart. Here we lose
> track of what he actually ordered even if we manage to salvage the
> payment.
>
> Here is a brief of the approach that has worked for me - it handles
> only cases (a) and (b). I am still working out a solution for (c)
> It may not be the most suitable implementation per spree's way of
> thought but it works for me -
>
> Assumptions:
> There will be only one hosted payment gateway - atleast thats my
> requirement so I didn't make it generic. Once I get to a stable
> working version, I may refactor it.
>
> Steps:
> a) Create a new extension for the payment gateway with 2 models.
> RequestLog and ResponseLog.
> Request log will record all attempts to the payment gateway(with order
> details) and ResponseLog will log all responses good or bad from the
> gateway.
> This can also be useful for debugging.
> To handle the broken flow outlined above, we need to be able to
> recreate the order from the request log if the need arises.
> c) create a controller with a return method (with its route) and
> create a method that you can configure as your return url
> d) Create a model for your pamentgateway that extends Gateway.
> Override
>   def method_type
>     "hosted_gateway"
>   end
> This will give you access to a new partial which will be called from
> _payment.html.erb
>
> Under app/views/checkouts/payment, create a _hosted_gateway.html.erb
> that will be called for your hosted gateway
>
> Note: I conditionally removed everything from _payment.html if
> @payment_methods.length == 1 and @payment_methods.method_type
> =="hosted_gateway" and included only partial in that case (this is
> because of my assumption) - you can also add another step in the
> checkout instead of riding over payments, but I ran into issues with
> that and hence this approach
>
> My _hosted_gateway.html.erb looks like this:
>
> <form action="<%=payment_method.request_url %>" method="post">
>
>   <% payment_method.request_form_fields(@order).each do |tag| %>
>     <%= tag %>
>   <% end %>
>
>   <%= submit_tag %>
> </form>
>
> request_url and request_form_fields are implemented by the payment
> gateway. to help build the form that will post to the gateway.
> The gateway in my case was configured (via the request params) to
> callback the url configured in (c)
>
> my return method looks like this:
>
>   def process_return
>     ccavenue = PaymentMethod.find_by_type('Gateway::CCAvenue')
>     order, is_payment_success = ccavenue.process_response(params)
>
>     if is_payment_success
>       checkout = order.checkout
>       checkout.payments.clear
>       payment = order.checkout.payments.create
>       payment.amount = params[:Amount]
>       payment.payment_method = ccavenue
>       checkout.save
>       checkout.next!
>
>       if checkout.completed_at
>         session[:order_id] = nil
>         flash[:commerce_tracking] =
> I18n.t("notice_messages.track_me_in_GA")
>       end
>
>       redirect_to order_url(order, {:checkout_complete => true})
>     else
>       #todo: failure needs to be handled properly
>       redirect_to order_checkout_path(order)
>     end
>
> This has been long! hopefully it helps you. If anyone else has a
> better shot at this problem I would be glad to test/extend it :)
>
> -Ajay
>
> On Mar 15, 12:06 am, Cameron <czcar...@gmail.com> wrote:
>
> > Hi Ajay,
>
> > If you manage to accomplish this would appreciate a write-up of some
> > description - after talking to a couple of providers in NZ, they all
> > strongly "suggest" I use a redirect to a hosted page, curious as to
> > how you work it out,
>
> > Regards,
>
> > Cameron
>
> > On Mar 10, 11:34 am, BryanMTL <bryan...@gmail.com> wrote:
>
> > > Hi Ajay,
>
> > > I recently completed something for this. I'm just reviewing it with
> > > the client and I believe he has plans on open-sourcing it.
>
> > > On Mar 9, 3:01 pm, Ajay CB <ajay...@gmail.com> wrote:
>
> > > > I am looking at implementing a new Payment Gateway on spree edge.
>
> > > > Requirement is to do a client side redirect to the payment gateway
> > > > (where the payment is made) and on successful completion - i.e
> > > > redirect to the success url, the order gets confirmed (checkout
> > > > complete) on failure, make the customer retry the payment (basically
> > > > another url endpoint for failure).
>
> > > > On the admin side, pretty much everything is manual - it sucks but I
> > > > am stuck with this gateway. The workflow to settle a payment is
> > > > closest to cheques. i.e just finalizing the payment will suffice.
>
> > > > Is there any existing payment gateway that works on this model, that I
> > > > can look at for an example?
> > > > If not what is the best way of going about this on the edge, given the
> > > > payment gateway refactoring.
>
> > > > Any suggestions/pointers will be of great help.
>
> > > > Thanks!
> > > > -Ajay
>
>

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