There is currently no way to edit the data in transactions once they're being processed. A common issue: user tries to make purchase, e.g., through authorize_net. The payment is disallowed because billing address doesn't match the credit card information. There is no way to go back and edit the address.
This is complicated by the fact that at this point we have the address stored in two different places. 1, whatever record it was originally entered into, e.g., through the address module or ecivicrm. 2. in the ec_transaction_address table. We don't want to edit just the data in the ec_transaction_address here, because then the error will reappear with the next transaction. What we need to be able to do is return to edit the originating record and have that update the transaction data, then return us to our transaction--e.g., the attempted purchase.
Here's a rough and untested patch in that direction (on 4.7). We introduce a new hook, _ec_transaction_error_edit(), that can be invoked when there is an error processing a transaction. This allows relevant modules to provide link-back options for editing the data that were fed into the transaction. As in initial example, I've sketched in what it would look like for authorize_net and ecivicrm.
When authorize_net generates an error, it invokes the new hook. ecivicrm returns a link for editing the transaction address, passing additional arguments that alert the edit process that a transaction is being edited.
It's very rough and won't work in its current form. For example, when updating the transaction address data, I haven't converted the ecivicrm format to that expected by store_transaction_addresses_save(). (I don't immediately see where this conversion is done elsewhere.)
Some feedback on the approach would be great. Is this useful? Is it unneeded because of some post 4.7 improvement?
| Comment | File | Size | Author |
|---|---|---|---|
| hook_transaction_error_edit.patch | 3.1 KB | nedjo |
Comments
Comment #1
gordon commented-1, I don't like this hook.
Generally you should be able to edit the address of a transaction after it has been created, but only to a certain point. I think that once the payment has been made they no more edits can be made by the customer.
I would implement this much in the same method as the being able to make payments later. You should be able to edit the address. And it should not matter that if you are using the address module, or ecivicrm to edit the address. You should just edit the address directly on the transaction.
I don't know about editing the shipping address, as this can alter the cost of shipping, handling. (In fact changing the billing address may impact tax)
Comment #2
nedjoThanks for the comments. Agreed, what we need is not a new hook but a way to go back and edit the whole transaction, since as you point out the new data entered may affect other aspects of the transaction (shipping, tax, etc.).
Currently, so far as I understand, a transaction is passed from an active editing state to a saved one when we initiate payment.
So I guess we need to do one of two things:
1. We keep the transaction editable when it's sent to payment, expiring it only when payment is successful.
2. We provide a way to revive a transaction for editing after it's been sent to payment.
Which is the better approach? What do we need to do to implement one or the other?
Comment #3
jeff veit commentedDefinitely the store owner should always be able to change anything about a transaction. Even once it's been recorded by the system.
Yesterday I ended up having to edit some data in an table, by hand, to change the record of a transaction - I needed to remove an unwanted item from a COD purchase. I don't see Joe Storeowner doing that.
For a transaction that fails, pretty much everything should be editable by the buyer. Then the transaction should be re-submittable.
For a transaction that succeeds, if payment has not yet been received, and the storeowner agrees, possibly through the use of a setting to indicate policy, anything should be changeable by the buyer. For instance, if the buyer wants to make a change to address on COD, that's fine, as long as the storeowner agrees. If they want to add something to the cart, then that may be fine, if the storeowner agrees - for instance, it may be a substitue for another item. Or it may be an increase in the sale.
For a transaction that succeeds, and payment has been received - for instance, using paypal - anything should be changeable by the buyer, subject to the approval of the store owner. You have to have approval because you do not want to change the basket of goods without the explicit approval of the store. Nor do you want to change delivery address without the approval of the storeowner.
Jeff
Comment #4
Anonymous (not verified) commentedFor what its worth, I don't think you should ever change a transaction once it has been submitted to payment for processing. If the payment gateway rejects the credit card then the customer should have the opportunity to review all aspects of the transaction (address selection, products, quantity, credit card details) and then resubmit as a new transaction with the new transaction entry referring back to the original transaction as a reference.
This allows the customer to fix problems with any aspect of the order (over the card limit, wrong address etc.) and preserve the transaction history so that the store owner knows what is going on.
Comment #5
Charles Oertel commentedMy wife has run an online seed store (finebushpeople.co.za) for 9 years. I built it in Perl (OK, those are my credentials so don't flip the bozo bit on me now). I am rebuilding the site in Drupal and after putting in multiple currencies, shipping for South Africa, a card API to our bank, I am now stuck on this most crucial issue.
I theory transactions should not be changeable so that there is a history. In practice of running a small business, product substitutions happen after conclusion of the order, quantities are changed, items are out of stock etc. In addition (and I see very little catering for this in the current system), the card payment is not 'final' for 'mail' order systems like this: on order placement, the order amount is 'authorized' against the customer's credit card. When the order is shipped, the authorized amount (or a smaller amount if items were out of stock) is 'settled'.
I have had to add the 'authorized' and 'settled' payment statuses to the system, and it is crucial that the the order quantities and items can be edited on an authorized transaction (BTW, for a shop owner, 'transaction' should be replaced with 'order').
Right now I am trying to add patches to allow my wife to 'settle' an authorized transaction, and to change order details (such as quantities and items etc). I am pretty sure that this level of back-end admin is critical to most online companies that ship tangible goods.
Does anybody have suggestions on how to so this in a way that re-uses the code that does the cart etc in the first place? It seems stupid to rewrite code that is already there.
Comment #6
simefixing component
Comment #7
brmassa commentedim closing this issue coz the modules changed too much since. if the situation persist, please, reopen it