views:

301

answers:

6

I have a requirement to be able to accept different forms of payment within the same order - ie not just the usual credit card or paypal for the whole thing, but perhaps paypal for one item, cheque for another. I know this sounds quite crazy, but there is a good business reason for the requirement so I can't just push back.

The best way I can think of implementing it at the moment is to have kind of a hub page, where you can "launch off" into multiple flows for each of the payments by opening new windows. I can't figure out a way of doing this in a linear flow as for example you can't guarantee that a user will come back from paypal, so you'd then lose the user completely.

Is there a neater way of doing this that anyone can think of, or can anyone point me to an example of a site that does somethign similar for inspiration?

A: 

If possible, just separate your order into separate smaller orders based off of the payment selections of the user.

And don't do it linearly. If anything you could open up each payment processor in a separate window so that you maintain presence.

TheTXI
A: 

Even when opening several windows at once, there is no guarantee that the user will complete all payment methods. So you are most probably going to lose a few users or payments. Be sure to send automated e-mail follow-ups for missing payments to minimize this problem. The e-mails could contain links to your payment providers for easy accesss to their outstanding payment operations.

Adrian Grigore
A: 

This is a difficult problem, but how many payment processors do you have to go offsite for? Should only be paypal.

In any case, I'd give the user all their payment options on one page, and let them fill in the amount for each processor or payment type. Then the next page would list those they chose, the amount for each, and a link to "Complete this payment".

The link would open in a new window.

You'll have to have a good back end and javascript, as well as user warnings so that the payment page gets updated as each payment is processed. Consider using popup dialogs to show that a payment has completed, or that the order has sat idle for more than 10-30 minutes without complete payment.

Also, consider sending emails and letting the user complete the payments through links in the emails. Send a new email each time a payment is completed, and a final email if all payments are complete and the order is moving forward.

Send an email one hour, and one day later for uncompleted orders with remaining payments required, that also give them the option of choosing different payment options for the remainder.

Email isn't best (lose more orders that way due to changing minds) but it's good for the type of transactions you're thinking about.

Adam Davis
There are actually many major payment processors that only work offsite. Take ShareIt, Avangate, RegNet, RegNow RegSoft,...
Adrian Grigore
+1  A: 

Personally, I'd do it like this:

  1. Let the user fill their basket in the ususal way
  2. Allow them to add payment types and amounts to a list (2nd basket almost)
  3. When the payments balance against the basket, start processing the payments
  4. For external sites, try a frame which has a progress indicator at the top.

In an ideal world it wouldn't be linear. But a lot of users might lose a spawned window, or get confused by the parallelism.

Better to stick to established IxD principals and rely on good feedback instead. Give the user control from the outset and keep it transparent.

Lastly, start the payment process with the most immediate (e.g. paypal) to reduce users giving up. (COD should come last!)

Hope this helps,

Tom

Tom Wright
A: 

I would take an approach where the whole order is broken down into sub-orders for each of the necessary payment methods. You can load the PayPal portion, the check portion, etc. and process them separately. It's important for the user to know how much is being charged to each of their payment methods, so it makes sense in this case to present the whole order as broken down by payment method (versus displaying as a unified order).

Implementation would be easiest if it's always a certain subset of items that is forced to any payment method. If this differs by user, or if it's when the order reaches a certain amount, the situation could become much more complicated. Can you be more specific about your approach?

tedmiston
A: 

Processing Multiple Order Payments

  1. Give the user the option to make a payment for a pending order using any of your payment types.
  2. Let the user specify an (Amount <= [Order Total] - [Payments Received]), if that is part of your requirement.
  3. If the order is still pending after you process the payment (see how below), take them back to step 1 to rinse and repeat.

How to store and process each payment made:

Use a Payments table to store all order payments, the PaymentMethod used and its Amount with its CurrencyCode.

  1. When a payment is received for an order, store the payment and sum all received amounts converted into your base currency as [Payments Received].
  2. If [Payments Received] >= [Order Total], mark the order as Paid. Or, if dealing with double-converted foreign exchange rates, check if it is correct to within a small-enough margin, eg 0.5%.
  3. Optionally, convert any overpayment into prepaid credit for the client.
FreshCode