#dg_docs
kind widgetBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1222637955441623062
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
lusty duneBOT
acoustic sorrel
Hello
You will receive a microdeposit based upon each PaymentMethod object that is created and needs to be verified.
You are saying that you aren't seeing that be the case?
lean hull
I am not - we saw that with 3 different PaymentMethod objects, attached to 3 different Customers, but pointing to a single external account (say routing number 11000000 and account number 000123456789), a single microdeposit (lets say a txn with descriptor SMABCD) will be created that can be used to validate each of the PaymentMethods
acoustic sorrel
Can you share those 3 PaymentMethod IDs?
lean hull
yes but quickly - you are a validated stripe employee? how can i confirm 🙂
acoustic sorrel
Yes I'm a Stripe Support Engineer.
If you aren't comfortable sharing information here then you can reach out to our Support team via https://support.stripe.com/contact/login
lean hull
i have spoken with the support team directly twice - their information seems to have been incorrect
can i send this to your stripe email?
acoustic sorrel
No, sorry. We can only communicate here.
Sharing object IDs is not sensitive -- no one can take action on them without your secret key
Never share your secret key and you are fine.
But like I said, if you still aren't comfortable sharing these object IDs then you need to work with Support. But I can't help further without looking at an actual example
lean hull
ok chatted with our security team they think its fine
1 sec
pm_1OyhRPB3hEhqM7EoiQyhayiG
pm_1OyhRqB3hEhqM7EoPtgpuI2T
pm_1OyhSXB3hEhqM7EoFoqppnPY
acoustic sorrel
Thanks, looking
Ah okay, I was incorrect, sorry. We do use a single microdeposit here. I wasn't aware of that and thought we still sent separate ones. But, it does make sense that if we sent separate microdeposits then there wouldn't really be a way to distinguish between which deposit was for which PaymentMethod.
lean hull
yeah! that was my thought - i think the internal docs might be out of date
acoustic sorrel
I do believe this may have changed when we switched to using statement descriptor microdeposits
As opposed to actual microdeposits with $$
lean hull
that is great to know - do you know if amount-based would still use a microdeposit per PaymentMethod?
stripe support said amount-based microdeposits were still used with banks that didn't support descriptor-based mds is why i ask
acoustic sorrel
I'd assume the behavior is the same but let me check
lean hull
ty, i appreciate it
acoustic sorrel
Okay everything I'm seeing indicates these behaviors are the same
lean hull
that is fantastic news, saves me like a week of building some weird customer-billing-group models
acoustic sorrel
Glad to hear it!
lean hull
last q - do you have a list of institutions that don't support descriptor-based mds that we could reference? we just want to prepare our customers as clearly as possible
kind widgetBOT
acoustic sorrel
That's my colleague. I have to step away, if you have follow up questions they can help you
lean hull
ok - tyvm @acoustic sorrel
@glacial ledge i think my last question is this: my team and i are planning to treat this behavior as canonical, and not a bug or just some temporary happenstance. can you confirm that the stripe team isn't planning to change this behavior in the near future?
acoustic sorrel
We don't have any plans to change this behavior that I'm aware of, nor would we change behavior like this without significant notice to merchants as it would break integrations.