Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.It seems there could be some serious errors for customer remote IDs.
It could happen when the "provider" is not properly set and it could be used by different Gateways with different API credentials (different merchand accounts)
For example #2859424: Braintree customer IDs are reused when the environment changes, this is for Braintree Payments integration
So there could be similar issues on other integrations, as Commerce Stripe and Commerce paymill
And maybe others.
1. So we need to help the existing issues, but updating the data there.
- Use payment gateway ids instead of module names for provider column.
- Clean-up the orphaned remote_ids, some remote_ids that were not usable anymore.
2. Provide API for the payments integrations that could help avoiding this issue
Comments
Comment #2
vasikeand there is a PR for this
https://github.com/drupalcommerce/commerce/pull/676
- Update script for updating the exising data (@see 1. in description).
- New methods for PaymentMethod entity to help Integrations: getOwnerRemoteId() & setOwnerRemoteId()
It uses the payment gateway id for the provider value.
- Update the PaymentMethodTest with new methods.
Questions:
- Do we need something else here?
- Why the user field is called : "commerce_remote_id", it looks too generic.
maybe a more specific name would be better: payment_method_remote_id or commerce_payment_remote_id?
ToDo:
Update other modules to use the new API, if approved.
waiting for feedback
Comment #3
vasikePR updated: Move the helper methods to PaymentGatewayBase from PaymentMethod.
Comment #4
bojanz commentedWrapping this up.
Comment #6
bojanz commentedRewrote the method to be self-healing, removing the need for an update hook.
Thank you vasike for getting this started.