Closed (fixed)
Project:
Commerce Saferpay
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
10 Jan 2013 at 10:58 UTC
Updated:
25 Jan 2013 at 12:30 UTC
Jump to comment: Most recent file
Implement the recurring payment charge callback for the commerce_saferpay_business payment method.
Comments
Comment #1
blueminds commentedPlease see attached patch.
Comment #2
berdirThis should not be necessary? This is only used for the credit card form, same for payment_method
Shouldn't we use the stored card data here? Meaning that the order should contain a reference to the used card on file id and then we should load that?
All we need for this is the card ref id, everything else should not be duplicated.
When does this happen? We should probably include a reference to the order that we tried to pay for (maybe use the link option?)
Not sure if this makes sense (we are not in a checkout process here), what is the state the order is in after the payment? I'd assume this is handled by the recurring framework somehow?
Comment #3
blueminds commented$order->data['payment_redirect_key'] = drupal_hash_base64(time());I assume that in case user wants to manually confirm the transaction, we need to provide this info to the remote service so it can authenticate upon the manual confirmation action.
RE copying the credit card info - to locally fetch the data we can, in that case, use only ref id which is part of the parent order, so is it okay to just do this?
$order->data['commerce_saferpay_card_ref_id'] = $parent_order->data['commerce_saferpay_card_ref_id'];The only thing that recurring does upon processing payment is this:
It does not handle order status nor does provide any hook on success. That is why I left it there... any suggestions?
Comment #4
blueminds commentedAlso now thinking about
$order->data['payment_method'] = $parent_order->data['payment_method'];It just implies that the payment method should be the same as for the parent order. Yes probably hardcoding the payment method would be the same, at least I do not see a use case when there will be a different payment method in that callback, but might happen in the future. But if you do not like it anyway I will hard code it ;)
Comment #5
berdirThis again, is only used for the checkout process, it tells the payment module which payment the user selected on the previous screen and which should be displayed to the user.
We are already within the payment method call, it is too late to switch to something else now anyway :)
Comment #6
blueminds commentedOkay, now I get it, but should not we capture this data just to be consistent - only to provide that info in the database?
Comment #7
berdirComment #8
berdirI'd check a module that already implements this, e.g. authorize.net in regards to status change and so on.
I would suggest that we do not copy the data around for now, that we don't actually need. I assume there is a link to the parent order, so you can look it up there if you need to.
Comment #9
blueminds commentedOki, then I suggest following:
- we need $order->data['payment_redirect_key'] = drupal_hash_base64(time()); as that data is used in commerce_saferpay_business_redirect_access().
- we definitely need $order->data['commerce_saferpay_card_ref_id'] = $parent_order->data['commerce_saferpay_card_ref_id']; as it is used to retrieve cc info
- and I suggest to keep $order->data['payment_method'] = $parent_order->data['payment_method']; just to be consistent in storing the data - it simply used some payment_method, so lets capture it
... then I removed commerce_order_status_update() call..
Please see the patch.
Comment #10
blueminds commentedAttaching patch without generating payment_redirect_key
Comment #11
berdirThanks, commited and pushed.