I have a few questions which I hope you have the time to answer.
The gateway I'm trying to cater for requires the form fields to be passed through as XML and I'm a little unsure where to implement the code which actually processes the payment.
Since this type of gateway doesn't use the standard Request Form, is the GenerateForm function required? What should go there?
Also in the call model, when does ProcessCallback and CapturePayment get called? What purpose do they serve?
Because of the XML, you cant use the default payment provider framework as it is based on posting a normal html form. So you will have to create your own code for this. What you will do it properly having a /base method that will generate the xml and post it and get a return/redirect. You would have to send a URL to them - maybe a continue url. Now when they hit your url at this place you will have to make some secutiry checks to validate the request - and if its valid you will have to invoke the Finalize method for the order.
Had another idea, how about I code the custom payment provider (inheriting from APayment) which generates the form as normal, however it posts to a page on my domain to process the XML from the html form.
What do you think?
How does the does ProcessCallback and CapturePayment fit into this model?
I think the main problem is that the way Tea Commerce uses the payment providers is that it expects them to return dictionary of string it will use to create a form and post it. But the idea of posting to a page on your domain that will use that data and generate the xml and use that sounds like a plan.
The callback is normally called from the payment gateway and to your servers to tell, server to server, that the payment is completed. Some data validation and verification should be implemented here - normally specified by the payment gateway api. Sometimes the payment gateway doesnt support a callback url. If it doesnt you can override the property FinalizeAtContinueUrl and return true. This will then have the payment provider know that at the continue url it will do a "fake" callback.
The capture/cancel/refund methods are methods used in the Tea Commerce admin area. If you go to an order an select the "Order Status" tab and its been captured with a payment provider that supports these method, you should se some UI buttons to click depending on the payment status of the order. Ex. if its "Authorized" - you should see a cancel and a capture button. Captured - you see a refund button.
Payment provider - XML Request/Response
Hi Anders,
Hi Bernard
Because of the XML, you cant use the default payment provider framework as it is based on posting a normal html form. So you will have to create your own code for this. What you will do it properly having a /base method that will generate the xml and post it and get a return/redirect. You would have to send a URL to them - maybe a continue url. Now when they hit your url at this place you will have to make some secutiry checks to validate the request - and if its valid you will have to invoke the Finalize method for the order.
Hope it makes sense.
Kind regards
Anders
I thought that was the case. Any chance you publish the code for the abstract class APayment so I can adapt the XML/Custom payment authorization?
Had another idea, how about I code the custom payment provider (inheriting from APayment) which generates the form as normal, however it posts to a page on my domain to process the XML from the html form.
What do you think?
How does the does ProcessCallback and CapturePayment fit into this model?
I think the main problem is that the way Tea Commerce uses the payment providers is that it expects them to return dictionary of string it will use to create a form and post it. But the idea of posting to a page on your domain that will use that data and generate the xml and use that sounds like a plan.
The callback is normally called from the payment gateway and to your servers to tell, server to server, that the payment is completed. Some data validation and verification should be implemented here - normally specified by the payment gateway api. Sometimes the payment gateway doesnt support a callback url. If it doesnt you can override the property FinalizeAtContinueUrl and return true. This will then have the payment provider know that at the continue url it will do a "fake" callback.
The capture/cancel/refund methods are methods used in the Tea Commerce admin area. If you go to an order an select the "Order Status" tab and its been captured with a payment provider that supports these method, you should se some UI buttons to click depending on the payment status of the order. Ex. if its "Authorized" - you should see a cancel and a capture button. Captured - you see a refund button.
Kind regards
Anders
is working on a reply...