Add support for refunds through the Server mode API.

"You can also use the information within the database to send remote requests for refunds and repeats. Unlike Form where there is a reliance on logging into My Sage Pay to perform refunds and repeat/releases in ALL circumstances, Server, with some additional coding, will allow you to push a button on your own software which will send a request to have a transaction refunded,"

from http://www.sagepay.com/help/faq/what_is_sage_pay_go_with_server_integration

Comments

leo pitt’s picture

leo pitt commented

Seems like a sensible request. Where would you prefer the "refund" button be placed?

md2’s picture

md2 commented

The placement is quite important, you don't want admins clicking a refund button by accident. The button should certainly ask for confirmation before issuing the refund call.

Has anyone had any thoughts into partial refunds, so if a user only wishes to return one item from an order.

Do you place a refund button beside each product on the order edit page? Along with refund entire order somewhere else on the order edit page? Possible in the payments pane?

Cheers,
Mark

dwkitchen’s picture

dwkitchen commented

md2's suggestions would work well.

It would also need to amend the order details for for sales reporting and tax calculations.

David

leo pitt’s picture

leo pitt commented

Agree with all points. I'll check out some other payment modules to see how they handle refunds, where the refund button is placed, and so on.

If there's an existing convention which works well then it would make sense to follow that...

Thanks

PlanetPHP’s picture

PlanetPHP commented

I've been looking into this a little bit with a view to implementing some form of refund (probably an amount <= order total). A question that seems to arise is what happens with the order status? After a quick search it seems other refund implementations add a negative entry in the payments table, therefore showing the order balance as a negative when the order is viewed. (The order overview screen shows no alteration).

The original ProtX system that I am moving from would log another 'order' as the refund with a RelatedVendorTxCode which would essentially overlay the previous order. That way you have a negative order (refund) that cancels out the positive (original) order. If this was a good solution we would then alter the order view to display the refund: check if there are any entries for the VendorTxCode of this order in the RelatedVendorTxCode field and display results.

Ideally it would be best to display that the order/item had been refunded and by how much, I keep thinking the structure of this should be standardised in ubercart rather than each payment module implementing all of this, however it likes to. Am I wrong? Obviously the payment module would have to handle the transaction.

For a similar discussion of this for PayPal: http://drupal.org/node/849350#comment-3185438