🇦🇹Austria @guedressel

guedressel → created an issue.

guedressel → created an issue.

We've the same requirement. Our solution is to store the tokens on the user session for later use (potential token refreshing).

Hooking to the "openid_connect_userinfo_save" did the job for us:

/**
 * Implements hook_openid_connect_userinfo_save().
 */
function helbling_user_openid_connect_userinfo_save(UserInterface $account, array $context): void {
	// Store OpenID Connect tokens for later use.
	$request = \Drupal::request();
	if( ! $request->hasSession() ) {
		// This is a strange situation: login via openid connect seem to have completed though no
		// PHP session is available required to keep Drupal's login state.
		// ¯\_(ツ)_/¯
		return;
	}
	$tokens = $context['tokens'];
	$request->getSession()->set('oidc_tokens', $tokens);
}

LGTM

BTW @mortona2k, I'm not sure if could have attributed your contribution in this issue in any way, since I just merged your merge request. I hope drupal.org is giving you credits for this issue anyways.

guedressel → created an issue.

Please check out the new release 3.0.0-beta1 → . It might clear the status report details up.
Though the README is still lacking details about the configuration of the module remote OPcache reset functionality.

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

I guess this is related to 📌 Monolog 3 support Active
@daniel.pernold you run monolog_datadog on monolog v3 - right?

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

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

@TrevorBradley I'm not sure what you tried to accomplish with your patches, but since a main aspect is to introduce the composer.json file into the module, you may use the merge request !2 in your projects composer.json until the maintainers create a new release including the D10 adoptions from that merge request.

You may want to read https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

Merge request !2 works fine.
Switching to RTBTC

guedressel → created an issue.

Today I undertook a mind-boggling dive into the sources of this module to find a path to implement SetupIntents and overcome the shortcomings with strong 3DS checks.
I learned a lot about the structure of commerce, commerce payment, commerce checkout, the Stripe API and - last but not least - commerce stripe 🤓

After some back and forth I might have found a quite straight forward modification to use SetupIntents. It was especially easy since SetupIntents were already in place to add payment methods outside a checkout flow.
I'll create an issue-fork to show you what I came up with. It's supposed to have a foundation to iterate on - and to build UnitTests.

Stripe API docs state:

By using SetupIntents, you ensure that your customers experience the minimum set of required friction, even as regulations change over time.

So I vote for using SetupIntents over PaymentIntents with "setup_future_usage".

I also discovered, that the PaymentMethodAddForm already creates SetupIntents for authenticated users:
https://git.drupalcode.org/project/commerce_stripe/-/blob/8.x-1.0/src/Pl...

Though I don't understand yet why this happens that way. This code was created in context of #3039032: 3D Secure 2 →

guedressel → created an issue.

Another chat with the Stripe support gave following suggestions:

• "Our documentation mentions that creating and attaching payment methods using the Payment Method API directly will cause these issues": https://stripe.com/docs/api/payment_methods/attach
• "What was recommended is for you to use the Setupintents API instead, or a payment intent API with the setup future usage property so a payment is taken and method is saved at the same time"
  https://stripe.com/docs/payments/save-and-reuse
  https://stripe.com/docs/payments/save-during-payment

Asking for test card-numbers wasn't very helpful, I just got reminded to have a look at https://support.stripe.com/questions/test-card-requiring-3d-secure-authe...

We updated our site to commerce_stripe 1.0-rc10, however some Mastercards still get rejected - hence no difference to 1.0-rc7.
On this site only one patch gets applied 📌 Allow translating Strip error messages. Needs review No further code modifications are in place for commerce_stripe.

So far we only tracked down only Mastercards (DebitCards and Credit cards aswell). We know of some cards issued from different Austrian banks, but we can't get any details on the cards from Stripe - neither for the logs in the dashboard nor from the Stripe support.

The Steps are configured like this:

Payment

• Contact information
• Payment information

Review

• Review
• Stripe review
• Agree to legal terms

Yes - the stripe review checkout pane is active, one step after the "Payment Information" checkout pane (where the API error response happens).

And no - we are currently on 1.0-rc7. Issue ✨ Allow for payments without stripe review pane Fixed may influence the behavior in question, though I doubt it.
We well upgrade our site and report back if anything changed.

Updating the required version of composer/installers package resolves this issue.

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

For the record: the monolog upgrade doc

guedressel → created an issue.

guedressel → created an issue.

+++ b/pathologic.module
@@ -192,10 +199,18 @@ function _pathologic_replace($matches) {
+  // file url starting with 'sites/default/files' (or with a leading slash).
...
+    preg_match('/sites\/(.*?)\/files\//', $parts['path'], $files_matches);

The public file path is configurable - see https://www.drupal.org/node/22241 →

Please check on actual path, instead of hard-coding patterns for the default path.