Warning thrown if given_name or family_name not enabled as part of address

Here's a patch for the warnings.

It seems we need to do it like this:

/** @var \Drupal\address\Plugin\Field\FieldType\AddressItem $address */
$address = $profile->get('address')->first();

And then use methods from the AddressItem class, such as $address->getGivenName() and $address->getFamilyName().
A good example of how it should be is here https://git.drupalcode.org/project/commerce_paypal/-/blob/8.x-1.x/src/Ch..., see method formatAddress().
So, in our case, we can also create a general method to format the billing and shipping addresses. The only problem now is that we don't have a file (sdk or api) for it yet.

Note: this is also happening in https://git.drupalcode.org/project/commerce_stripe/-/blame/8.x-1.x/src/P... .

Here's the patch unifying address formatting.

A few notes on design decisions:

1) The address formatter is implemented as a Drupal service to allow overriding it.
2) The \Drupal\commerce_stripe\AddressFormatterInterface::format() method accepts the whole Profile entity to allow customizing the data retrieved; as a common example, sometimes site owners adds phone number field to the customer profile and thus it should be possible to extract it and pass to Stripe.

1.1 broke these patches. Here's a try at updating the full refactor one for 1.1. I will also turn this into an issue fork.

I realized that a good place for the formatAddress method is the StripePaymentElement plugin. So I moved the code from the separate service to this plugin and updated the corresponding code (+ opened MR).

I tested this patch on a local install that I disabled all name and company fields from in the default customer profile type. When I tried to pay, I was shown errors related to a missing shipping[name] parameter. How did you test this? Maybe we need some way to still provide a name for a shipment even if this works fine for billing?

@rszrama
Yes, you're right, the shipping name field is required https://stripe.com/docs/api/payment_intents/create#create_payment_intent... (if the address is defined, then the name must exist).
I've updated the MR with the necessary fixes.

Thanks, this worked for me. I think we can worry about refactoring the address formatting out to a service in the future that standardizes both this and various other common API features between the payment gateway plugins.

Automatically closed - issue fixed for 2 weeks with no activity.