I'm looking into creating a new payment provider, but the flow seems a bit different to the existing ones in the GitHub repo, so I could do with some advice on the best way to do this with a provider in TeaCommerce.
The flow is as follows:
we make a call to an endpoint, which sets up the order and gives us some tokens that we then use to display an iframe
the customer fills in their details on a payment form in the iframe
the customer is redirected back to a URL on our website
our website must then make a call to another endpoint to determine if the order was successful or not, and then we display the success or failure page, dependant on the response from the API
Looking at the existing example providers, I'm not 100% sure how to do this. I presume I'd do the checking of the second endpoint in the process callback method?
There doesn't seem to be any documentation that explains the process/flow for a payment provider or how they work, so I'm struggling to visualise what I'd need to do for our example flow.
Any help or pointers would be greatly appreciated!
Hmmm, you could do something a bit like the stripe provider https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/tree/master/Source/TeaCommerce.PaymentProviders.Stripe In this provider, instead of posting to a 3rd party payment gateway, it's posts to another page on your site where you hold the logic for displaying the payment form (in your scenario it would be to render the iframe) and then when it knows it's finished, it redirects to the TC generated continue URL to finalize the order.
Also in the stripe payment provider, you can see how it uses the payment providers communication URL in order to communicate back to the payment provider https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/blob/master/Source/TeaCommerce.PaymentProviders.UI/Views/Partials/StripePaymentForm.cshtml#L197 here the "api_url" is posted through from the GenerateHtmlForm method and appends a querystring so you know you are communicating with it for a specific purpose (over the default webhook handling). So with this you can post to your payment provider and it can make the server call to the third part to check the payment status (unless you can do it directly from JS).
I think with those two approaches you should be able to get something working for your needs.
I've had a look at the stripe provider, and I've got a few questions. Would the GenerateHtmlForm be the best place to get the token and add to the form? Should I initialize the payment and set the token as payment metadata, or store it against the order?
Is it the ProcessCallback method that gets called when the form is submitted? Can I redirect to the iframe page from there? If so, how?
Finally, which URL should I pass to the payment provider to return back to, and what is the corresponding function in the provider so that I can get the token I set earlier and check the outcome of the payment and finalize/update the order accordingly? And again, can you issue a redirect from there to either the success or failure URLs?
The Stripe form looks like it does a lot of stuff in the JS, and I'm hoping to do all of this server side if possible to keep it simple.
Ok, do you have an example of what the "iframe" response the payment gateway returns to you? Or documentation from the payment gateway about their API?
Yes GenerateHtmlForm is where you would initialize the payment with the payment gateway. You can either embed the returned token into the generated payment form, which will then get posted to the payment page, or you could save it as property data on the order. The later would mean the value isn't exposed, but you'd have to retrieve it from the order on the payment form page.
The ProcessCallback method is generally called either from a webhook from the payment gateway, or when you redirect to the continue URL Tea Commerce provides you if the payment provider is configured to finalize at continue (a boolean property on the payment provider).
Generally you should pass the teaCommerceContinueUrl that is passed to the GenerateHtmlForm to the payment gateway. If you need to send it to the gateway at a point outside of that method, then you should store that url on the order as a property and access it from the order later on. You need to use this URL as it performs some TC functions before redirecting to the payment methods continue URL. If you need this URL to finalize the order, you should configure your payment provider to "finalizeAtContinue" and then this will call the ProcessCallback method in which you can process the querystring and finalize the order.
So the iframe response is what sets up the actual order on their system, and gives you a "token" to identify the transaction. You post some XML to a URL on the payment provider, and you get some XML back with two tokens that you need to use later. If we store them in the order, we can get to them later. As part of the XML we send, we give them a return URL that the iframe loads over the parent page once it's done. For this it sounds like I give the continue URL.
If I make that call in the GenerateHtmlForm method, I can have a confirmation page that show a summary of the order and the form submit button/form output. Hitting the submit button should take us to the page on our site that displays the iframe. We can pull the token out of the CurrentOrder object for rendering out the iframe. Looking at the stripe provider, you set the form_url to be your custom form page, so I can do the same.
Once the payment has been collected, the payment provider loads the URL we sent it over the top of the iframe's parent page, it doesn't provide anything else, it's just a dumb get with no additional data. If that's the TC continue URL, I guess I can add the logic to the ProcessCallback to use the saved token to access the order, and update with payment state (success or fail) and store the merchant transaction ID against the order, and finalise the order if everything was OK.
Can I redirect from within the ProcessCallback though?
Assuming ProcessCallback is being called via the continue URL, you shouldn't need to redirect as it will call callback and then continue to the confirmation page anyway. Failing this, if you know the ProcessCallback is being called in the context of your request pipeline (ie, not vai webhook or anything) then you could grab the current HttpContext and for a redirect by modifying the response object. I think we did this before in the original Stripe provider but don't seem to need to now.
I'm so close to having this working! I just have an issue with he workflow that I'm not sure about.
I'm generating all the tokens in the GenerateFormHtml fine, and as long as I have FinaliseOnContinue set, it all seems to work with regards to the callback, the only issue I have is that if a payment fails, I don't want to finalise the order, as they can retry.
My workaround at the moment is to set FinaliseOnContinue to false, and then have the teacommerceCallbackUrl as the return URL and then I have to manually Finalise there. Which works, however, teaCommerce doesn't then fire the redirect to the confirmation page, so I'm having to do it manually.
Is this the best way to do this, or is there a "better" way, that works with all the TeaCommerce pipeline natively?
Hmmm, the only other approach I could think of is within the GenerateHtmlForm method you stash the teaCommerceContinueUrl and the teaCommerceCancelUrl in the order as properties and then set the return URL of the payment gateway to actually be the teaCommerceCommunicationUrl. This will then send you to a ProcessRequest method on the payment provider that you can implement and essentially handle the whole request.
From within this method then, you could check the request to see if it was successful or failed and depending on the outcome, redirect to the teaCommerceContinueUrl or teaCommerceCancelUrl that was stored on the order accordingly by forcing a Request.Redirect.
This way you only hit the continue / callback URL if successfull, otherwise you get sent back to the cancel URL to try again.
New Payment Provider
I'm looking into creating a new payment provider, but the flow seems a bit different to the existing ones in the GitHub repo, so I could do with some advice on the best way to do this with a provider in TeaCommerce.
The flow is as follows:
Looking at the existing example providers, I'm not 100% sure how to do this. I presume I'd do the checking of the second endpoint in the process callback method?
There doesn't seem to be any documentation that explains the process/flow for a payment provider or how they work, so I'm struggling to visualise what I'd need to do for our example flow.
Any help or pointers would be greatly appreciated!
:)
Hi Tim,
Hmmm, you could do something a bit like the stripe provider https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/tree/master/Source/TeaCommerce.PaymentProviders.Stripe In this provider, instead of posting to a 3rd party payment gateway, it's posts to another page on your site where you hold the logic for displaying the payment form (in your scenario it would be to render the iframe) and then when it knows it's finished, it redirects to the TC generated continue URL to finalize the order.
Also in the stripe payment provider, you can see how it uses the payment providers communication URL in order to communicate back to the payment provider https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/blob/master/Source/TeaCommerce.PaymentProviders.UI/Views/Partials/StripePaymentForm.cshtml#L197 here the "api_url" is posted through from the
GenerateHtmlFormmethod and appends a querystring so you know you are communicating with it for a specific purpose (over the default webhook handling). So with this you can post to your payment provider and it can make the server call to the third part to check the payment status (unless you can do it directly from JS).I think with those two approaches you should be able to get something working for your needs.
Matt
Thanks Matt!
I'll take a look at the Stripe Provider and see what I can re-use/adapt. I'll give you a shout if I have any questions.
:)
Hi Matt,
I've had a look at the stripe provider, and I've got a few questions. Would the GenerateHtmlForm be the best place to get the token and add to the form? Should I initialize the payment and set the token as payment metadata, or store it against the order?
Is it the ProcessCallback method that gets called when the form is submitted? Can I redirect to the iframe page from there? If so, how?
Finally, which URL should I pass to the payment provider to return back to, and what is the corresponding function in the provider so that I can get the token I set earlier and check the outcome of the payment and finalize/update the order accordingly? And again, can you issue a redirect from there to either the success or failure URLs?
The Stripe form looks like it does a lot of stuff in the JS, and I'm hoping to do all of this server side if possible to keep it simple.
Hi Tim,
Ok, do you have an example of what the "iframe" response the payment gateway returns to you? Or documentation from the payment gateway about their API?
Yes
GenerateHtmlFormis where you would initialize the payment with the payment gateway. You can either embed the returned token into the generated payment form, which will then get posted to the payment page, or you could save it as property data on the order. The later would mean the value isn't exposed, but you'd have to retrieve it from the order on the payment form page.The ProcessCallback method is generally called either from a webhook from the payment gateway, or when you redirect to the continue URL Tea Commerce provides you if the payment provider is configured to finalize at continue (a boolean property on the payment provider).
Generally you should pass the
teaCommerceContinueUrlthat is passed to the GenerateHtmlForm to the payment gateway. If you need to send it to the gateway at a point outside of that method, then you should store that url on the order as a property and access it from the order later on. You need to use this URL as it performs some TC functions before redirecting to the payment methods continue URL. If you need this URL to finalize the order, you should configure your payment provider to "finalizeAtContinue" and then this will call theProcessCallbackmethod in which you can process the querystring and finalize the order.Matt
Hi Matt!
So the iframe response is what sets up the actual order on their system, and gives you a "token" to identify the transaction. You post some XML to a URL on the payment provider, and you get some XML back with two tokens that you need to use later. If we store them in the order, we can get to them later. As part of the XML we send, we give them a return URL that the iframe loads over the parent page once it's done. For this it sounds like I give the continue URL.
If I make that call in the GenerateHtmlForm method, I can have a confirmation page that show a summary of the order and the form submit button/form output. Hitting the submit button should take us to the page on our site that displays the iframe. We can pull the token out of the CurrentOrder object for rendering out the iframe. Looking at the stripe provider, you set the form_url to be your custom form page, so I can do the same.
Once the payment has been collected, the payment provider loads the URL we sent it over the top of the iframe's parent page, it doesn't provide anything else, it's just a dumb get with no additional data. If that's the TC continue URL, I guess I can add the logic to the ProcessCallback to use the saved token to access the order, and update with payment state (success or fail) and store the merchant transaction ID against the order, and finalise the order if everything was OK.
Can I redirect from within the ProcessCallback though?
Assuming ProcessCallback is being called via the continue URL, you shouldn't need to redirect as it will call callback and then continue to the confirmation page anyway. Failing this, if you know the ProcessCallback is being called in the context of your request pipeline (ie, not vai webhook or anything) then you could grab the current HttpContext and for a redirect by modifying the response object. I think we did this before in the original Stripe provider but don't seem to need to now.
Matt
Awesome, thanks Matt, that's super helpful :)
Hi Matt,
I'm so close to having this working! I just have an issue with he workflow that I'm not sure about.
I'm generating all the tokens in the GenerateFormHtml fine, and as long as I have FinaliseOnContinue set, it all seems to work with regards to the callback, the only issue I have is that if a payment fails, I don't want to finalise the order, as they can retry.
My workaround at the moment is to set FinaliseOnContinue to false, and then have the teacommerceCallbackUrl as the return URL and then I have to manually Finalise there. Which works, however, teaCommerce doesn't then fire the redirect to the confirmation page, so I'm having to do it manually.
Is this the best way to do this, or is there a "better" way, that works with all the TeaCommerce pipeline natively?
Hmmm, the only other approach I could think of is within the
GenerateHtmlFormmethod you stash theteaCommerceContinueUrland theteaCommerceCancelUrlin the order as properties and then set the return URL of the payment gateway to actually be theteaCommerceCommunicationUrl. This will then send you to aProcessRequestmethod on the payment provider that you can implement and essentially handle the whole request.From within this method then, you could check the request to see if it was successful or failed and depending on the outcome, redirect to the
teaCommerceContinueUrlorteaCommerceCancelUrlthat was stored on the order accordingly by forcing a Request.Redirect.This way you only hit the continue / callback URL if successfull, otherwise you get sent back to the cancel URL to try again.
Hope this helps
Matt
is working on a reply...