If I'm on Payments Provider version 3.0.6 (via latest TC) - has this stuff been merged or do I need to compile this change myself?
Also the client has been advised to move to Stripe Elements (I believe the major difference is that the payment is taken via an iFrame so less chance of scraping).
If I wanted to implement this is it best to branch the Payment Provider solution and roll this myself based on the existing Stripe provider?
These changes haven't been merged in yet so the core version isn't running on the latest stripe.
There are two possible solutions:
1) Use my fork and run from a custom built DLL. I'm looking to merge my PR in, but I've had a message from Ste Roberts or Offroad Code to say they have more up to date code so I'm trying to get a copy of this to be on the latest.
2) Run on your current version but force the site to run on the latest TLS implementation. You can do this by implementing a Global class with the code below and updating the Global.asax to point to it.
using System.Net;
using System.Web;
namespace Website.Extensions.Utilities
{
public class Global : Umbraco.Web.UmbracoApplication
{
public Global()
{
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //TLS 1.2
}
}
}
Regarding using Stripe elements you should be able to upate the example StripeForm partial to use the latest javascript and use the elements controls. I've been reluctant to update this as I find the elements much harder to style consistantly, but if it's getting to the point the old approach is being depricated, we might need to look at updating it.
I think Stripe are looking to push people from v2 eventually. I'm getting this second hand though so don't take my word for it!
Out of interest - do you know if any of the TC out of the box payment providers either hand you off to the payment gateway or use an iframe? Client is now worried about PCI - I know inline post to payment gateway get token methods were (are?) compliant as you're not processing on your server exactly but it sounds like the sands are shifting with regards to having the credit card details entered even on your webpage.
The stripe approach is that you have inputs which are only used by stripe via their JS API to collect credit card details. Those are posted to stripe and that returns a token which is injected into your form. Those credi card inputs don't (or at least shouldn't) have an id or name attribute on them, which means the values won't get posted back to your server. Ultimately then, this means your back end server never comes into contact with credit card details, just the token, and thus your server doesn't need to be PCI complient. The only stipulation these services have is that the request must be made over HTTPS.
As far as I am aware, this all still holds true, so shouldn't be any additional PCI requirements for your server.
PS I have the updated code from Ste for the Stripe provider so I'll look to make an update to the payment providers repository on GitHub as soon as I can.
PPS In terms of payment providers that redirect, anything that isn't "inline" tends to have a redirect process, so think PayPal where you navigate to PayPal to pay for the product and get redirected back on completion.
Anything inline will generally use a JS / PCI complient solution such as the Stripe one mentioned above.
As far as I am aware, none of the core payment providers require you to have any special compliance levels beyond basic SSL.
I managed to get the code from Ste so I've created a new PR with the very latest implementation. I need to run some tests myself, but if you wanted to give it a go and send any feedback that would be super helpful. You can find my PR at
If you pull the branch and compile it locally you should be able drop the compiled dll + stripe dll in your bin folder and copy the example StripePaymentForm partial view as a starting point for the payment form (it might require you to update JSON.NET too, but I think it should be ok in a newer Umbraco install).
StripePaymentForm.cshtml Line 89 looks like it's missing an opening brace:
var tokenData = {
And I had to update the System.Collections.Immutable nuget package in my website as the callback failed but after that a test payment went through.
Looks like I need to look at the styling on my form to fit in with the site but this looks ace at first glimpse! Will have a proper test in the morning.
Oops, thanks Steve. I've updated my PR with the missing {.
System.Collections.Immutable could be interesting as this will likely mean we need to ship that with the package which could conflict with a nuget dependency. I need to look at creating a nuget package for TC, but we'll still need a regular umbraco package so need to think of the best way to deal with that.
RE styles, yea, the form is meant to be a baseline setup. You will need to tweak it to fit your sites design.
Yes - I'm afraid there doesn't seem to be an easy solution to this. I suppose the only thing I can say is that this isn't just a standard Umbraco package - if you install an ecommerce package it's probably central to your website goals so you'll accept there will be some setup issues / package restrictions.
Obviously you need / want to make it as accessible as possible.. difficult!
Just wanted to follow up on this. Not sure if you've been watching the PR on the GitHub repo, but I've now merged it all in after performing some end to end testing this afternoon.
In addition, I've also implemented a build script to merge + internalize all Payment Provider 3rd party dependencies into the main DLL so that it can avoid conflicts (only the Payment Providers can see them). It does mean you can't just update a 3rd party DLL independently, but I don't think people would really be doing that.
I need to sort out doing a full Tea Commerce release with the updated DLL, and probably need to add some code to delete the now unused 3rd party dependencies from the previous build (which are now merged in), but if you wanted to update manually, you can get the source from the dev branch on GitHub and run the Build.cmd file in the root to build and merge the DLL for you (it gets output into an Artifacts folder).
That sounds like a great solution. I've put a working demo for the Client to try Stripe Elements. When I get feedback from that I'll update with this and retest.
Just built a release version of the DLL from the dev branch... all looked good except something goes wrong on the callback / confirmation.
I'm getting the basket wiped out but no confirmation email - the order number is null.
This is what's in the log. Is there anyway to hook the debugger in to help fix this?
Steve
2019-01-30 14:37:10,051 [P1852/D15/T48] INFO TeaCommerce.PaymentProviders.Inline.Stripe - Form:
stripeToken : tok_1DyKBcGHfpkiarixcjk1TSEj
2019-01-30 14:37:10,051 [P1852/D15/T48] ERROR TeaCommerce.PaymentProviders.Inline.Stripe - Stripe(CART-145) - ProcessCallback
System.NullReferenceException: Object reference not set to an instance of an object.
at TeaCommerce.PaymentProviders.Inline.Stripe.ProcessCallback(Order order, HttpRequest request, IDictionary`2 settings)
I'm betting the MetaData property isn't initialized, so rather than calling Add, I just need to set MetaData to a new dictionary. I'll get that updated now and you can try it out.
Hmm, that's a strange one, you could try compiling the project in debug mode (from visual studio) and copy the dlls + pdb files over and adding a breakpoint into the ProcessCallback method to see what's going on. I believe it should be debugable.
Tea Commerce and Stripe (and Stripe Elements)
Hi,
I'm upgrading a site that never went live. Since updating TC the payments are now failing (perhaps they always did?!).
I know the TLS requirements were changed for Stripe and can see Matt did some work https://github.com/TeaCommerce/Payment-providers/pull/15
If I'm on Payments Provider version 3.0.6 (via latest TC) - has this stuff been merged or do I need to compile this change myself?
Also the client has been advised to move to Stripe Elements (I believe the major difference is that the payment is taken via an iFrame so less chance of scraping).
If I wanted to implement this is it best to branch the Payment Provider solution and roll this myself based on the existing Stripe provider?
Steve
Hi Steve,
These changes haven't been merged in yet so the core version isn't running on the latest stripe.
There are two possible solutions:
1) Use my fork and run from a custom built DLL. I'm looking to merge my PR in, but I've had a message from Ste Roberts or Offroad Code to say they have more up to date code so I'm trying to get a copy of this to be on the latest.
2) Run on your current version but force the site to run on the latest TLS implementation. You can do this by implementing a Global class with the code below and updating the Global.asax to point to it.
Regarding using Stripe elements you should be able to upate the example StripeForm partial to use the latest javascript and use the elements controls. I've been reluctant to update this as I find the elements much harder to style consistantly, but if it's getting to the point the old approach is being depricated, we might need to look at updating it.
Hope this helps
Matt
Hi Matt,
Thanks - that's really helpful.
I think Stripe are looking to push people from v2 eventually. I'm getting this second hand though so don't take my word for it!
Out of interest - do you know if any of the TC out of the box payment providers either hand you off to the payment gateway or use an iframe? Client is now worried about PCI - I know inline post to payment gateway get token methods were (are?) compliant as you're not processing on your server exactly but it sounds like the sands are shifting with regards to having the credit card details entered even on your webpage.
Steve
The stripe approach is that you have inputs which are only used by stripe via their JS API to collect credit card details. Those are posted to stripe and that returns a token which is injected into your form. Those credi card inputs don't (or at least shouldn't) have an id or name attribute on them, which means the values won't get posted back to your server. Ultimately then, this means your back end server never comes into contact with credit card details, just the token, and thus your server doesn't need to be PCI complient. The only stipulation these services have is that the request must be made over HTTPS.
As far as I am aware, this all still holds true, so shouldn't be any additional PCI requirements for your server.
PS I have the updated code from Ste for the Stripe provider so I'll look to make an update to the payment providers repository on GitHub as soon as I can.
PPS In terms of payment providers that redirect, anything that isn't "inline" tends to have a redirect process, so think PayPal where you navigate to PayPal to pay for the product and get redirected back on completion.
Anything inline will generally use a JS / PCI complient solution such as the Stripe one mentioned above.
As far as I am aware, none of the core payment providers require you to have any special compliance levels beyond basic SSL.
Thanks Matt
I know you've got a lot to pickup with this so I appreciate you taking the time to answer!
Hopefully I can help give back to TC at some point - either via payment provider code or licence sales!
Steve
Hey Steve,
I managed to get the code from Ste so I've created a new PR with the very latest implementation. I need to run some tests myself, but if you wanted to give it a go and send any feedback that would be super helpful. You can find my PR at
https://github.com/TeaCommerce/Payment-Providers/pull/19
If you pull the branch and compile it locally you should be able drop the compiled dll + stripe dll in your bin folder and copy the example StripePaymentForm partial view as a starting point for the payment form (it might require you to update JSON.NET too, but I think it should be ok in a newer Umbraco install).
Hi,
I will absolutely do this... cracking. Was about to have a go at this myself.
Cheers
Steve
Hi,
StripePaymentForm.cshtml Line 89 looks like it's missing an opening brace:
var tokenData = {
And I had to update the System.Collections.Immutable nuget package in my website as the callback failed but after that a test payment went through.
Looks like I need to look at the styling on my form to fit in with the site but this looks ace at first glimpse! Will have a proper test in the morning.
Steve
Oops, thanks Steve. I've updated my PR with the missing
{.System.Collections.Immutablecould be interesting as this will likely mean we need to ship that with the package which could conflict with a nuget dependency. I need to look at creating a nuget package for TC, but we'll still need a regular umbraco package so need to think of the best way to deal with that.RE styles, yea, the form is meant to be a baseline setup. You will need to tweak it to fit your sites design.
2019 and we still have dll hell!
Yes - I'm afraid there doesn't seem to be an easy solution to this. I suppose the only thing I can say is that this isn't just a standard Umbraco package - if you install an ecommerce package it's probably central to your website goals so you'll accept there will be some setup issues / package restrictions.
Obviously you need / want to make it as accessible as possible.. difficult!
Hey Steve,
Just wanted to follow up on this. Not sure if you've been watching the PR on the GitHub repo, but I've now merged it all in after performing some end to end testing this afternoon.
In addition, I've also implemented a build script to merge + internalize all Payment Provider 3rd party dependencies into the main DLL so that it can avoid conflicts (only the Payment Providers can see them). It does mean you can't just update a 3rd party DLL independently, but I don't think people would really be doing that.
I need to sort out doing a full Tea Commerce release with the updated DLL, and probably need to add some code to delete the now unused 3rd party dependencies from the previous build (which are now merged in), but if you wanted to update manually, you can get the source from the dev branch on GitHub and run the Build.cmd file in the root to build and merge the DLL for you (it gets output into an Artifacts folder).
https://github.com/TeaCommerce/Payment-Providers/tree/development
If you do do this, maybe just deleted the old 3rd party dependencies manually. These being:
I've also updated the example partial with the fixes you mentioned:
https://github.com/TeaCommerce/Payment-Providers/blob/development/Source/TeaCommerce.PaymentProviders.UI/Views/StripePaymentForm.cshtml
If you do give it a try, please do let me know if you find any issues.
Hi Matt,
That sounds like a great solution. I've put a working demo for the Client to try Stripe Elements. When I get feedback from that I'll update with this and retest.
I'll let you know how it goes though.
Kind regards
Steve
Hi Matt,
Just built a release version of the DLL from the dev branch... all looked good except something goes wrong on the callback / confirmation.
I'm getting the basket wiped out but no confirmation email - the order number is null.
This is what's in the log. Is there anyway to hook the debugger in to help fix this?
Steve
2019-01-30 14:37:10,051 [P1852/D15/T48] INFO TeaCommerce.PaymentProviders.Inline.Stripe - Form: stripeToken : tok_1DyKBcGHfpkiarixcjk1TSEj
2019-01-30 14:37:10,051 [P1852/D15/T48] ERROR TeaCommerce.PaymentProviders.Inline.Stripe - Stripe(CART-145) - ProcessCallback System.NullReferenceException: Object reference not set to an instance of an object. at TeaCommerce.PaymentProviders.Inline.Stripe.ProcessCallback(Order order, HttpRequest request, IDictionary`2 settings)
Rolled it back to the version you supplied before and it seems to work.
Steve
Ahh, in that case I think I might know would it will be. I think I recently moved the cartNumber to stripe meta data fields
https://github.com/TeaCommerce/Payment-Providers/blob/dev/Source/TeaCommerce.PaymentProviders/Inline/Stripe.cs#L113
I'm betting the
MetaDataproperty isn't initialized, so rather than calling Add, I just need to setMetaDatato a new dictionary. I'll get that updated now and you can try it out.Update pushed to the git repo.
Thanks for trying this out.
Yup - that sorted it!
Thanks
Steve
Just to let you know, the new Stripe providers are in the 3.3.0 release going out today. Thanks for testing.
Hmm, that's a strange one, you could try compiling the project in debug mode (from visual studio) and copy the dlls + pdb files over and adding a breakpoint into the ProcessCallback method to see what's going on. I believe it should be debugable.
is working on a reply...