I am in the process of rewriting the Stripe payment provider using the latest version of Stripe, and adding support for additional payment methods (e.g. iDEAL). Could someone help with answering the following:
What is the difference between the teaCommerceContinueUrl, teaCommerceCallbackUrl, and teaCommerceCommunicationUrl? When should which one be used?
What is the purpose of the ProcessCallback and ProcessRequest methods? What code should be in each?
How does the value of FinalizeAtContinueUrl affect things?
teaCommerceContinueUrl
This is the success url. The payment gateway should redirect to this address when the payment is finished
teaCommerceCallbackUrl
Is the url the payment gateway should call with a status after the user have finished the payment. The url is autogenerated by Tea Commerce and in the end you ProcessCallback method will be called.
teaCommerceCommunicationUrl
I think this is only used in a few inline payment providers. I'm not entirely sure what its used for but it will call the ProcessRequest method
*ProcessCallback *
As mentioned this method will automatically be called when the payment gateway answers back to teaCommerceCallbackUrl
*ProcessRequest *
This is only for inline payment providers. Will be called when the payment gateway answers to the teaCommerceCommunicationUrl
FinalizeAtContinueUrl
If this is true the teaCommerceCallbackUrl will not be used. The ProcessCallback method will be called when the user is sent to the continue url instead. Some payment gateways work like that.
I have been looking at the source code for TeaCommerce.PaymentProviders, but most of the glue is in the TeaCommerce.Api.Web namespace (e.g. the TeaCommerceHelper.PaymentContinue and related methods), and this code is not open source (would be very helpful if it was...).
In the latest Stripe API implementing webhooks have become necessary for many payment methods, and the reason for me starting this thread was to get a better understanding of how to implement them using TeaCommerce.
From what I can see now it is not possible to use any of the built-in url's as a Stripe webhook url, and I have instead added a custom controller and action which will forward the event to a static method on the payment provider.
Also, if I understand everything correctly, I will set the FinalizeAtContinueUrl to false and reimplement the code in ProcessCallback as new methods called by that webhooks static method.
At this point I think I have a good handle on everything and am moving forward.
A quick question, what's the difference between "classic" and "inline" payment providers?
What we call Classic payment providers is the ones that steal the window and where the user leaves the website to make the payment. After payment the user is redirected back to the website. The website and the payment provider will exchange information in different ways underway.
An Inline payment provider does not steal the window. Everything happens on the website itself and you use the payment gateways API to make the transaction. These are normally a lot more complicated to make.
Help with implementing payment providers
I am in the process of rewriting the Stripe payment provider using the latest version of Stripe, and adding support for additional payment methods (e.g. iDEAL). Could someone help with answering the following:
Thanks, -Tor
Hi Tor
teaCommerceContinueUrl This is the success url. The payment gateway should redirect to this address when the payment is finished
teaCommerceCallbackUrl Is the url the payment gateway should call with a status after the user have finished the payment. The url is autogenerated by Tea Commerce and in the end you ProcessCallback method will be called.
teaCommerceCommunicationUrl I think this is only used in a few inline payment providers. I'm not entirely sure what its used for but it will call the ProcessRequest method
*ProcessCallback * As mentioned this method will automatically be called when the payment gateway answers back to teaCommerceCallbackUrl
*ProcessRequest * This is only for inline payment providers. Will be called when the payment gateway answers to the teaCommerceCommunicationUrl
FinalizeAtContinueUrl If this is true the teaCommerceCallbackUrl will not be used. The ProcessCallback method will be called when the user is sent to the continue url instead. Some payment gateways work like that.
If you want to know how they are used search for them in the payment providers project: https://github.com/TeaCommerce/Payment-providers/search?q=FinalizeAtContinueUrl&unscoped_q=FinalizeAtContinueUrl
/Rune
Hi Rune,
I have been looking at the source code for TeaCommerce.PaymentProviders, but most of the glue is in the TeaCommerce.Api.Web namespace (e.g. the TeaCommerceHelper.PaymentContinue and related methods), and this code is not open source (would be very helpful if it was...).
In the latest Stripe API implementing webhooks have become necessary for many payment methods, and the reason for me starting this thread was to get a better understanding of how to implement them using TeaCommerce.
From what I can see now it is not possible to use any of the built-in url's as a Stripe webhook url, and I have instead added a custom controller and action which will forward the event to a static method on the payment provider.
Also, if I understand everything correctly, I will set the FinalizeAtContinueUrl to false and reimplement the code in ProcessCallback as new methods called by that webhooks static method.
At this point I think I have a good handle on everything and am moving forward.
A quick question, what's the difference between "classic" and "inline" payment providers?
-Tor
That is a good question :)
What we call Classic payment providers is the ones that steal the window and where the user leaves the website to make the payment. After payment the user is redirected back to the website. The website and the payment provider will exchange information in different ways underway.
An Inline payment provider does not steal the window. Everything happens on the website itself and you use the payment gateways API to make the transaction. These are normally a lot more complicated to make.
/Rune
is working on a reply...