@vamshi27I do think you could make your life easier by testing your server side code on localhost. The client side tokenization cannot be worked around from what it sounds. The tokenized data can be replaced with a dummy credit card number in an API call. I would build my transaction request exactly as I wanted it served side, set my sandbox to be as lax as possible so that I could avoid duplicate transactions kick backs and fraud triggers as much as possible. Once your server side code is executing exactly like you want, you would have a baseline to start with and could be sure that any subsequent issues were coming from the client side.
Then you would take out the cc info and put in the data descriptor and payment nonce in its place and start testing from either a live server or a TLS enabled localhost. Live server is just as easy for client side testing in my experience. You get error logging in the console. As a side note I’m biting my tongue pretty hard right now. The amount of unnecessary bashing and complaining by developers on this freely provided forum is something else. I’ll just say that the grass isn’t greener anywhere else, as I just googled the https issue and Stripe has required TLS 1.2 connections for all API library initiated calls since July of 2018, and was https only before then. It’s frustrating but I suppose that’s why we don’t do it for free (except me, sometimes). Best of luck to you and hope to hear of some great progress.
