Closed toppa closed 10 years ago
Agreed. At least for the first iteration of the gem, the token should be exposed to the controller either through a query method or a callback.
E.g. the controller action could look like this:
def create
# some stuff happens
current_user.update_attributes payment_token: cybersource_response.token
end
I have it so the class that handles the response can be passed a block which it will yield the transaction result params to. So you can do this kind of thing:
redirect_to response_handler.run { |result| Rails.logger.info result[:params]['payment_token'] }
You could of course read the params directly yourself, but the yield is happening after the signature verification (which you also get the status of, in another field), so I'm thinking it's an appropriate place for this kind of hook.
Let me know if that sounds ok. I'm doing a pairing session with Greg tonight, so I'll review this with him too.
After reviewing this with Greg, I decided to remove the yield block. All the data it yields is already available within the scope of the controller (the params, the result of the signature check, which profile we are using) so its not adding any significant value.
So the short answer is, users of the gem can simply read the payment token value directly from the Cybersource response. I'm not sure wrapping it up in something else really adds anything.
For supporting recurring payments, what should we do with payment tokens? In a regular app they would probably be associated with user accounts in some fashion. Maybe we can provide a hook where users of our gem can read them when they're set from Cybersource? Then they can save them however is appropriate for their app.