#juananbipi

1 messages · Page 1 of 1 (latest)

sage summitBOT
scenic knot
#

Hi
Can you share an example please ?

royal cape
#

Yeah, of course this event evt_1OUtUmIBSQ06oPXFMohcVpAO and this request req_iqt4t5QAXte8Lz. Same payment method id, same IBAN, different fingerprint

scenic knot
#

The event Id you've shared was triggered for this requestId req_B74eoOYZE5wuXb and not the one you are sharing

royal cape
#

Yes, we know, but shouldn't a payment_method always have the same fingerprint wherever it is retrieved? We use fingerprinting to detect duplicate IBANs between customers and these inconsistencies can affect our data consistency.

#

We didn't get this behavior in cards, only in SEPAs.

scenic knot
#

Can you share more details about your integration flow? why are you calling /attach endpoint after completting the Setupintent ?

tardy edge
#

Yep, agreed the differing fingerprints does look unexpected. We can raise this internally with the SEPA team and figure out what's going on

#

In the meantime, your /attach call is redundant. Because you're providing customer parameter on SI creation we will automatically attach the generated PM to the cus_xxx on confirmation

royal cape
#

Yeah, we are right now refactoring that part. We used to not provided customerId on SetupIntent creation. But this weird behavior worries us, in case we don't really understand what a fingerprint is for SEPA. We assume that the same iban always generates the same fingerprint.

tardy edge
#

I would expect the IBAN fingerprint to match in the API response and the Event payload where the IBAN details are the same, as per docs:

Uniquely identifies this particular bank account. You can use this attribute to check whether two bank accounts are the same.
https://stripe.com/docs/api/payment_methods/object#payment_method_object-sepa_debit-fingerprint

#

But that's nothing you can fix/change right now, and we'll raise it with the SEPA team to understand the cause and fix if required

#

If you retrieve that pm_xxx ID via the API, what is the fingerprint in the response?

royal cape
#

YnagYx0GkWIyI3lx (the same of the event)

tardy edge
#

Yeah I suspect this is specifically an issue on the /attach endpoint which is largely redundant anyway as I explained

#

If you're refactoring to remove that part from your integration then the fingerprint will match otherwise

sage summitBOT
royal cape
#

Ok, do you know if this is a bug unique to the testing environment? We were not able to reproduce it in live mode

tardy edge
#

Perhaps, unfortunately I've no idea right now (wasn't even aware of this specific issue until you've raised it)

royal cape
#

Ok, if you are going to escalate the bug to the appropriate team keep me posted.

tardy edge
#

If you want to be updated on any fixes/changes, you'll need to write in to support: https://support.stripe.com/contact

#

I'll raise with the team today