Hi @maltfield ,
Greetings from WebToffee Support.
Thank you for your message and your concerns about the OAuth implementation. We understand your preference for Restricted API Keys, and we value your feedback. To clarify how our plugin handles sensitive payment information, here’s a detailed explanation:
- Client-Side Tokenization : Our plugin uses Stripe’s JavaScript library (Stripe.js) to handle sensitive payment information directly in the customer’s browser. This means that credit card numbers and other sensitive data are sent directly to Stripe’s secure servers, bypassing your server entirely.
- Token-Based Transactions : After Stripe processes the payment information, a token is generated. This token represents the payment details and is sent to your server. Your server then uses this token to interact with Stripe’s API for creating charges or managing subscriptions.
- No Sensitive Data on Your Server : Only the token is stored or processed on your server, not the actual credit card details. This keeps your server outside of PCI compliance. The token is a secure reference to the payment information stored on Stripe’s infrastructure.
- OAuth Implementation and Data Storage : We use our server for token refreshing between Stripe and your server. The server at verify-stripe.webtoffee.com facilitates the process where the client’s site sends the refresh token and account ID to our server. From there, a request is sent to Stripe for new access tokens, refresh tokens, and publishable keys. The response is then sent back to the client. This server is registered at the Platform account of WebToffee. The access tokens, refresh tokens, publishable keys, and account IDs are stored in your WordPress site’s options table under the following names:
- Test Account Data :
- wt_stripe_access_token_test
- wt_stripe_refresh_token_test
- wt_stripe_test_publishable_key
- wt_stripe_account_id_test
- Live Account Data :
- wt_stripe_access_token_live
- wt_stripe_refresh_token_live
- wt_stripe_live_publishable_key
- wt_stripe_account_id_live
Payment-related requests are not handled by our server; it only facilitates the process of refreshing tokens and relaying responses.
Regarding Your Issue:
If you’re facing difficulties with customers being unable to pay via credit cards after updating the plugin, could you kindly provide the following:
- Error Messages : Are you seeing any error messages in the checkout process?
- Logs : Please provide the eh_stripe_pay_dead logs and wt_stripe_oauth logs from WooCommerce → Status → Logs.
You can privately share these logs with us using this link. This information will help us debug the issue and identify the cause of the payment problem.
Looking forward to your response and assisting you further.
We use our server for token refreshing between Stripe and your server.
The server at verify-stripe.webtoffee.com facilitates the process where
the client’s site sends the refresh token and account ID to our server.
Sorry, but we can’t allow our OAuth tokens to pass through a third party.
Do you have any plans to let my server handle the refresh tokens directly with Stripe?
I created this issue on the GitHub to address this security risk:
Hi @maltfield,
It looks like the GitHub link you shared is for a different plugin. Could you please double-check to ensure you’re using our plugin? If you’re looking for support, we’re happy to help you navigate it!
If you want to share any improvement suggestions or send us any logs, use this link.
Yes, sorry, I shared the wrong link. I think I got confused because I couldn’t find your public forge.
> If you want to share any improvement suggestions or send us any logs, use this link.
Sorry, I don’t think it’s appropriate to have this conversation behind an authwall.
Please create a public place for people to submit feature requests and bug reports. I recommend GitHub, GitLab, or Codeberg.
Hi,
Can you please state what OAuth Flow you use for Stripe Connect with this application?
After much research and back-and-forth with Stripe Support, they said admitted that some OAuth flows expose the OAuth bearer tokens with a third party (which is a security risk) and some other OAuth flows do not.
They said that merchants cannot control which OAuth flow is used, and it depends on what was implemented by the developer. Stripe support asked me to ask the developer which OAuth flow they use in their implementation of Stripe Connect.
Can you please tell us which specific OAuth flow you use for Stripe Connect in this application?
Thank you
Hi @maltfield,
Thank you for your query.
The plugin uses the Standard OAuth 2.0 Authorization Code Grant flow. This flow ensures that the authorization and token exchange process is handled securely between your site and Stripe.
Please feel free to reach out if you need any further clarification.
The plugin uses the Standard OAuth 2.0 Authorization Code Grant flow. This flow ensures that the authorization and token exchange process is handled securely between your site and Stripe.
Unfortunately, this is incorrect.
That flow (Authorization Code Grant) does *not* ensure that the token exchange process is securely handled between your user’s sites and Stripe’s servers.
The correct flow for that would be the “Authorization Code with PKCE” flow.
I confirmed with Stripe support that plugins using the “Authorization Code” flow are insecure, as they leak the critically-important bearer token with the third party’s servers.
Do you have an ETA on when you can fix this plugin to actually support secure OAuth flow by replacing the “Authorization Code” flow with the “Authorization Code with PKCE” flow?
