🇸🇾Syria @hodba

hodba → created an issue.

As per the documentation related to New API for defining field type categories → . We need to remove the category translation from the field type annotation, create a new MODULE.field_type_categories.yml, and lastly add a backward compatibility.

I implemented the needed work in the attached patch.

hodba → created an issue.

Did you put the stripe payment field in the same page with the fields that you want to use as tokens? if this is the case, the tokens are not generated yet to pass their values to the stripe payment element. When you put the payment in a new page, the form builder will pass its values.
Otherwise you need to alter the webform and add ajax callback to update the values of the stripe payment element.

I am facing the issue upgrading from 2.9. Many styles are breaking because of this. +1

If I understood it correctly, you are emailing the invoices to clients with a link and you want to set the amount automatically when they press the link.
If this is the case, you can use the prepopulated value of the amount in the link which is related to the webform module. What you need to do in this case is:
- Activate the prepopulate option in the webform configurations
- Construct the link to include the prepopulated value
- The only requirement is to have the prepopulated filed in a webform page and the Stripe field in one the following pages (not in the same page)

By doing this, it should be working fine.

Can you post your webform configurations we I can test the issue locally

Thanks for reporting this. Can you share some more details about the scenario, webform configurations, other details of your Drupal setup?
I am using the module in multiple websites and never had such an issue.

Rerolled for 3.0@beta and adding a fix error "Error sending email: Email "" does not comply with addr-spec of RFC 2822." when CC or BCC fields are empty.
Tested with Drupal 10.

Thanks for reporting this, I will check and provide a fix if needed.

hi, just have the time to follow up on this. Would you please list the steps to reproduce the issue including the webfom configurations e.g. multipage enabled, ajax enabled...etc.

Hi,
sorry for the late reply, I was extremely busy the this month. if you're still having the issue, we can have a quick Zoom meeting to check what is happening at your end. For me, I tested it and it is working fine.

Thank you solar for providing the fix.
I added temporarly this to the latest 1.x dev branch until providing permanent fix to loop through pages and get all product.

Can you please list the steps to reproduce this issue.

Is there any error in the log? are you using the live or test Stripe API keys?

Thanks for reporting this issues. let me check and get back to you shortly.

I see where the issue is.

In order to pick up the price as a token, you need to separate the payment field in a new page where the calculation is done before proceeding to the payment. This is due to the fact that Stripe element needs to generate the payment intent before the payment form is loaded. When you put the price as a token in the Stripe element, and place all elements in one page, the paymentIntent is generated before the token can be used.

Hope this helps you resolve the issue.

Best,

Can you provide me more details please about your specific case in details? e.g. how the Weform is configured? Are you using multistep webform? did you please it at the end? does the total number and the stripe element are on the same page?
did you try [webform:element:order_total] without the value?

Thank you dr. gubó for the patch. It's fixed and added to the latest dev.

Fixed and added to the latest dev branch.

I will add the note about it.

Thanks for reporting this.

I think the issue is that the email address element and the Stripe payment element are in the same webform page so the token of the email is not generated yet to be used in the Stripe payment intent and that is why your seeing this error.

As a workaround, you can put the payment in a separate webform page so users can fill the email in the first page, then do the payment in the second one. This will get the value of the email and pass it as a token to the payment intent.

Can you please try it and let me know if this works for you?

I tested the module again with a custom amount and token. The custom amount element tested against textfield and number webform elements and it worked fine for me.
Can you export your webform and paste it here so I can test your use case?

Always happy to help. Please feel free to discover the module, and I'll appreciate any feedback.

The fix is added to the 1.0.0-alpha4 release

The module works with PHP 8.1, and this error looks like generated from an older PHP version.

Can you please confirm the PHP version that generated the error?

Thanks for the patch.

The code is updated in 1.0.0-dev, and social_core is added as a dependency to the rc_opensocial module.

In order to speed up the process, I created a dummy account on Stripe that can be used to test the module faster:
Publishable key: pk_test_51J7tbHL9kB28upArnW0kNF4GotNU0Yu6Ox6NotfCmVSgwDbxfGUF7rHI5HdGNsem6hiGPkwcWmxaP4DjFuNLuRHv00H5W8L1xy

Secret key: sk_test_51J7tbHL9kB28upAriUrtKYnf6j8LCuyTNr1gnc77NXeHlhH4ETaCKflNlyVFEQeJ8MBUO2A73jwwW2hX4swdE0BX00uMgn9bjF

Please make sure to use them in the test keys section. These keys are created as a dummy and have no effect on the account and will be deleted after the verification is completed.

Hope to hear from you soon :)

The issue is fixed and added to the latest 1.0.0-alpha3

The suggested code enhancements are added to the latest 1.0.0-alpha3

The suggested fix is added to the 1.0.0-alpha3 release.

hodba → made their first commit to this issue’s fork.

Thanks sidharth_soman. I added your fix to the latest 1.0.x-dev

hodba → made their first commit to this issue’s fork.

Actually, the fields of the billing and shipping address element are defined by Stripe and determined by the requirements of the payment methods. Unfortunately, we cannot control for most elements what fields to show or hide. I would advise you not to enable the address field of Stripe, and use the webform address element to collect it, then include it as a token in the Stripe paymentIntent configuration in the module.
You can learn about customizing the paymentIntent element in this blog post

The billing address is defined as a placeholder in the "form-element--stripe-payment.html.twig". You can see the div with "address-element" ID.
If you want to change its place, you can do it from the template, but you can't implement it separately, as it is called while creating the payment intent.

Regarding sending invoices by email, I think the best way is to manage it from the Stripe admin panel.

Thak you vishal.kadam
The code is updated as instructed.

hodba → created an issue.

Applying the tested changes as per the rector's suggestions.

Hey @andyrigby,

Thanks for your valuable feedback. I appreciate the detailed problem statement and potential solutions you've provided.

The module was initially created with a focus on credit card payments, so your suggestion about incorporating the SetupIntent into the module to support direct debit for recurring payments is a fresh perspective. It's a valid point and would certainly broaden the scope and usability of the module.

While I am maintaining this project in my spare time, I recognize the importance of your proposal and will add it to our roadmap. However, immediate implementation may not be feasible due to my current schedule. I will be happy to discuss this feature request on a Zoom call. You can book a time on my calendar @ https://hodba.me

#8 worked for me. Thanks Leksat!

As this module focuses on Stripe Card Payment, I developed a new module that is built around Stripe Payment Element that allows to configure the payment intent and can handle the case of “pay mater”.
Have a look at it at https://www.drupal.org/project/stripe_webform_payment#top →

Thanks for stopping by. Actually, your patch will not work in the implementation as the StripeCustomerPortalStripe service does not use the StringTranslationTrait.
I will update the code soon to allow using $this->t() method.

Let's fix them one by one.
I updated the code to accept tokens by converting the token value (text, number, or decimal) to a float value that Stripe accepts. Can you check the latest dev version and let me know if it is working for your use case?

If I got your point right and the node is available to the webform, then you can use the token of the field in the price.
Can you check if this works for you?

Can you please list the environment and the steps to reproduce the issue? I tested it, and I don't get the error.

Update docs to be aligned with Rocket.Chat 6.x

Thank you Rajab :)

hodba → created an issue.

Thank you Rajab for the follow-up, I am deploying it in a local environment, and I am pretty sure that I have the minimum requirements. Surprisingly, it's working fine on the production server with no issues.

I will close this for now and recheck my local configurations and get back to you with my findings.

Hiding personal info

hodba → created an issue. See original summary → .