#deemeetree1234_api

1 messages ยท Page 1 of 1 (latest)

timber echoBOT
#

๐Ÿ‘‹ 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.

slim fox
#

So you're asking "how can I know if a card is a Stripe-issued (Issuing) card while being processed on a Stripe account"?

timber echoBOT
wide veldt
#

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

  1. At step 2, is it possible to know that the card was issued from Stripe Account A?
  2. At step 3, is it possible to put some arbitrary data on the PaymentIntent which would propagate to the Authorization WebHook?
  3. 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?
tame viper
#

Hi hi! Iโ€™m going to be taking over for my colleague here. Give me a minute to read back and understand things.

wide veldt
#

save me timebox

tame viper
#

I'm just a chicken, man. Temper your expectations.

#

๐Ÿ˜‚

wide veldt
#

you are the golden egg from which the chicken came

tame viper
wide veldt
#

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?

tame viper
#

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?

wide veldt
#

Yes both stripe accounts belong to the same company but one is used for issuing and the other one is used for payment processing

tame viper
#

Wait what does that mean?

wide veldt
#

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

tame viper
#

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.

wide veldt
#

Lol yeah sorry I dont know how else to describe it. Are you familiar with the term acquirer?

tame viper
#

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?

wide veldt
#

The platform account which is issuing cards will have multiple connected accounts

tame viper
#

Isn't the platform issuing cards to Connected Accounts belonging to other companies/people?

wide veldt
#

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

tame viper
wide veldt
#

yes we are doing that

#

in Stripe Account A

tame viper
#

Now I'm even more confused.

#
ci => Card Issuing Account
pp => Payment Processing Account```
Tell me about the `ci` and `pp` accounts.
wide veldt
#

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?

tame viper
#

Yes.

#

So tell me about the pa and pp.

wide veldt
#

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?

tame viper
#

Yes. You're saying this: pa -> ci -> issued_card

And you're wondering about this: pa.charge(issued_card)

Right?

wide veldt
#

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.

tame viper
#

๐Ÿ˜‚

wide veldt
#

and that means pp.charge(issued_card) right?

tame viper
#

<but why gif>

#

(It got annoying ๐Ÿ˜‚)

#

It conceivably means pa -> pp.charge(issued_card) depending on how the pa <> pp link is built.

wide veldt
#

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

tame viper
#

Are pa and pp connected at all (like, via Connect)?

wide veldt
#

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?

tame viper
#

Ohhhhh, ok.

#

Gimme just a sec to rejig my brain.

tame viper
#

Ok, your ultimate goal here is "how do we process that charge without having to pay Stripe," right?

wide veldt
#

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

tame viper
#

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.

wide veldt
#

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?!

tame viper
#

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.