#deemeetree1234_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1362188139602640960
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
So you're asking "how can I know if a card is a Stripe-issued (Issuing) card while being processed on a Stripe account"?
So this is the scenario
Step 1 - Account A issues a credit card to a cardholder under Stripe Account A
Step 2 - Cardholder adds that card as a payment method in Account B
Step 3 - Cardholder creates payment intent using that card in Account B
Step 4 - Account A receieves Webhook authorization request for that transaction
Questions
- At step 2, is it possible to know that the card was issued from Stripe Account A?
- At step 3, is it possible to put some arbitrary data on the PaymentIntent which would propagate to the Authorization WebHook?
- At step 4, is it possible to put some arbitrary data on to the authorization before approving it, that would appear on the Payment Intent response?
Hi hi! Iโm going to be taking over for my colleague here. Give me a minute to read back and understand things.
save me timebox
you are the golden egg from which the chicken came
https://docs.stripe.com/api/events/types#event_types-issuing_card.created and the subsequent events should be received on your Connect webhook (which would include the associated Stripe Account ID). That solves 1.
2, 3, 4 should all be addressed by issuing_authorization.created events.
Sorry im not following. For this
https://docs.stripe.com/api/events/types#event_types-issuing_card.created and the subsequent events should be received on your Connect webhook (which would include the associated Stripe Account ID). That solves 1.
Are you saying that when a payment method in account B is added, then the issuer account (Account A), gets a webhook saing that the issued card was used in a different account?
Ah crap. I misnumbered.
Or rather, we used two sets of offset numbers. ๐
When Stripe knows the card has been used, it will emit an issuing_authorization.created event. You can use that to know it's been used, but not anything about Account B.
Is Account B on your platform too? Is that the idea?
Yes both stripe accounts belong to the same company but one is used for issuing and the other one is used for payment processing
Wait what does that mean?
So like Stripe Account A is setup as an issuer and can issue credits cards. Then if an end user takes one of those cards and adds it as a pyment method to their account, it would get added to Stripe Account B. The end users customer records exist in Stripe Account B. They may or may not be the original cardholder that the card was issued to.
Say we issue a card to a Acme Business. The company gives that card to one of their employees who makes an account on our website. Then they take the card that was issued to Acme Business and adds it to their user account as a payment method for buying things on our website. When they make a purchase on our website, we will process that payment through Stripe Account B.
Does that make sense?
Then stripe handles that payment intent and does its magic and Stripe Account A, which is also owned by the same company that owns Stripe Account B, will get the authorization webhook
The problem is that there is nothing on this webhook authorization object that I can use to tie back to the purchase on the website. It doesnt look like there any details or metadata that can be set on the Payment Intent that would appear on the webhook authorization event
Is there only one Account B? Or is it an example of a class which might contain hundreds of "Account B" instances?
Sorry, we've confused things with letters and numbers.
Lol yeah sorry I dont know how else to describe it. Are you familiar with the term acquirer?
Hold on.
Does your Platform Account only have multiple Connected Accounts that are issued cards, or does it also have multiple Connected Accounts that your Platform handles processing payments for?
The platform account which is issuing cards will have multiple connected accounts
Isn't the platform issuing cards to Connected Accounts belonging to other companies/people?
yes the connected accounts are businesses which are our customers and they will issue cards to their own employees as well as the business itself
that would all be happening in "Stripe Account A"
But the goal is to know if the cards were issued from the platform account I guess, not from a specific connected account thats under that platform account
Generally when issuing cards to entites separate from your business entity, those should all be done as Connected Accounts. https://docs.stripe.com/issuing/connect#when-to-use-connect
Now I'm even more confused.
ci => Card Issuing Account
pp => Payment Processing Account```
Tell me about the `ci` and `pp` accounts.
Tell me if this is accurate, maybe our language is off. The pa has 1 or more connected accounts under it. Those connected accounts can issue charge cards to their employees. Are we on the same page with that?
ok so the pa and pp are totally different Stripe accounts, they are just owned/registered to the same company. So the company/business that owns the pa also owns the pp
But say one of the employees of the businesses that is a connected account under the pa , went to the the website of the pa to make a purchase. They have their own user on that website and their user can have credit cards associated with it, it could be their own personal credit card, it could be the charge card their company issued to them, does that make sense?
Yes. You're saying this: pa -> ci -> issued_card
And you're wondering about this: pa.charge(issued_card)
Right?
no so when that end user goes and buys something on our website and they pay with that charge card their company issued to them, my company processes that payment through the pp.
๐
and that means pp.charge(issued_card) right?
<but why gif>
(It got annoying ๐)
It conceivably means pa -> pp.charge(issued_card) depending on how the pa <> pp link is built.
lol so my company just uses the pp to charage all credit cards (as it sits today), if the end user adds the card that was issued to them, we dont see a way to determine that the card was issued from our pa so we just treat it like any other credit card
Are pa and pp connected at all (like, via Connect)?
nope
they are just owned by my company
so my understanding is that if a charge is done in the pp then the pa will receieve the issuing authorization webhook, right?
Ok, your ultimate goal here is "how do we process that charge without having to pay Stripe," right?
No, our goal is to be able to associate these types of transactions with the transactions stored in the service that consumes the webhook events. That service will be doing the client invoicing and needs details about the transaction that was made to put on the invoice. We cant completely control the way end users add these payment cards to their account so there is a chance this type of disconnect can occur and there can be a break in our data.
Stripe always gets its due
I gotta leave in a minute but will be back later. Seems like you have a good understanding of what we're trying to do, so I would love your insight. But like I said the end goal is to be able to associate the data we get on the webhook, with the data thats set on the payment intent and sent to the pp. That way we can call our services internally and get the missing details needed for the transaction on the webhook
TL;DR is: you'll have to build something that maps issued_cards to pp.transactions. Not sure how exactly to pull that off, but whoever's here will do their damnedest to help when you return.
This thread will close in a half hour or so, but will remain available to both you and whoever's helping you so the context isn't lost.
Do I just open a new thread when Im back or something?
and why did you say our ultimate goal was to not pay stripe? How does this avoid paying stripe?!
Haha
Yes, you do that, with the same Discord user, and you'll get this thread back.
I said that because for internal use like that, where you're the issuer and the merchant, it doesn't really make sense to pay fees just to pay yourself, if that makes sense?
That said, it would be a lot of work, and a substantial change to the UX, to make that work. ยฏ_(ใ)_/ยฏ
Also, because I want to help you do what's best for your business. If that's also good for Stripe, awesome. If not, still awesome as long as it helps your business.