#kurisu

1 messages · Page 1 of 1 (latest)

lyric steepleBOT
dawn kayak
#

Hi there!

#

Give me a few minutes to look into this.

#

The webhook endpoint you shared is a Connect endpoint. However the PaymentIntent you shared was directly made on your account (not connect)

#

So it's expected that you don't see it here.

snow kite
#

mhm... our eventhandler respond to the same events successfully when forwarding with stripe CLI. what can we do?

#

look at that CLI test e.g.

2023-02-22 17:23:33 --> customer.created [evt_1MeL6PKyoozLJBGZmd9jtVBn]
2023-02-22 17:23:33 --> payment_intent.requires_action [evt_3MeL6OKyoozLJBGZ2rD060U7]
2023-02-22 17:23:33 --> payment_intent.created [evt_3MeL6OKyoozLJBGZ2EAMxban]
2023-02-22 17:23:34 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6PKyoozLJBGZmd9jtVBn]
2023-02-22 17:23:34 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_3MeL6OKyoozLJBGZ2EAMxban]
2023-02-22 17:23:34 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_3MeL6OKyoozLJBGZ2rD060U7]
2023-02-22 17:23:39 --> payment_intent.succeeded [evt_3MeL6OKyoozLJBGZ2fCXP2mH]
2023-02-22 17:23:39 --> checkout.session.completed [evt_1MeL6VKyoozLJBGZxFeQ4AW0]
2023-02-22 17:23:39 --> charge.succeeded [evt_3MeL6OKyoozLJBGZ2LVAb7V9]

summer valley
#

👋 taking over for my colleague. Let me catch up.

snow kite
#

2023-02-22 17:23:40 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6VKyoozLJBGZxFeQ4AW0]
2023-02-22 17:23:40 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_3MeL6OKyoozLJBGZ2LVAb7V9]
2023-02-22 17:23:41 --> transfer.created [evt_1MeL6XKyoozLJBGZYjuDHHZB]
2023-02-22 17:23:41 --> connect payment.created [evt_1MeL6X4KqOcqQ7DzQLQtazP3]
2023-02-22 17:23:41 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_3MeL6OKyoozLJBGZ2fCXP2mH]
2023-02-22 17:23:41 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6X4KqOcqQ7DzQLQtazP3]
2023-02-22 17:23:42 --> connect balance.available [evt_1MeL6Y4KqOcqQ7DzJxiJ6OUC]
2023-02-22 17:23:42 --> customer.updated [evt_1MeL6YKyoozLJBGZw8LYjxKk]
2023-02-22 17:23:42 --> invoice.created [evt_1MeL6YKyoozLJBGZfIQWe0Dl]

#

2023-02-22 17:23:42 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6Y4KqOcqQ7DzJxiJ6OUC]
2023-02-22 17:23:43 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6YKyoozLJBGZfIQWe0Dl]
2023-02-22 17:23:43 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6YKyoozLJBGZw8LYjxKk]
2023-02-22 17:23:43 --> invoice.updated [evt_1MeL6ZKyoozLJBGZoSWYP8r4]
2023-02-22 17:23:43 --> invoiceitem.created [evt_1MeL6ZKyoozLJBGZMt0MzSCZ]
2023-02-22 17:23:43 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6ZKyoozLJBGZoSWYP8r4]
2023-02-22 17:23:43 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6ZKyoozLJBGZMt0MzSCZ]
2023-02-22 17:23:44 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6XKyoozLJBGZYjuDHHZB]
2023-02-22 17:23:44 --> payment_intent.created [evt_3MeL6aKyoozLJBGZ1XhsGlDn]
2023-02-22 17:23:44 --> invoice.updated [evt_1MeL6aKyoozLJBGZSjI09bpb]
2023-02-22 17:23:44 --> invoice.finalized [evt_1MeL6aKyoozLJBGZN7wj3ToU]
2023-02-22 17:23:45 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_3MeL6aKyoozLJBGZ1XhsGlDn]
2023-02-22 17:23:45 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6aKyoozLJBGZSjI09bpb]
2023-02-22 17:23:45 <-- [200] POST https://localhost:6001/api/webhooks/index [evt_1MeL6aKyoozLJBGZN7wj3ToU]

#

thx @summer valley

summer valley
#

give me a minute to catch up and will be with you shortly

#

as my colleague explained, we have 2 types of webhooks:

  • one for your own events
  • another for the connected accounts events
#

in your case you just need to create a new one which listens to the events on your own account

snow kite
#

that seams very strange since the same scenario already worked as you can see below:

christian.sommer@wienerzeitung.at's payment for an invoice for €57.60 succeeded
evt_1Ma11CKyoozLJBGZywAnzLLI
2/10/23, 7:08:17 PM
christian.sommer@wienerzeitung.at's invoice for €57.60 was paid
evt_1Ma11CKyoozLJBGZ3cYbkK1i
2/10/23, 7:08:17 PM
christian.sommer@wienerzeitung.at's invoice for €57.60 was sent
evt_1Ma11CKyoozLJBGZXZeinPb0
2/10/23, 7:08:17 PM
A draft invoice for €57.60 to christian.sommer@wienerzeitung.at was finalized
evt_1Ma11CKyoozLJBGZ14FHHUpK
2/10/23, 7:08:17 PM
A draft invoice was created
evt_1Ma11BKyoozLJBGZDuo1KYqg
2/10/23, 7:08:17 PM
christian.sommer@wienerzeitung.at was charged €57.60
evt_3Ma112KyoozLJBGZ0r5Gd5z3
2/10/23, 7:08:16 PM
The payment pi_3Ma112KyoozLJBGZ0v0RWEZp for €57.60 has succeeded
evt_3Ma112KyoozLJBGZ0MZSJU2l
2/10/23, 7:08:16 PM
Previous
Next

summer valley
#

it depends on whether you created the object on your account or on a connect account

snow kite
#

above output uses both accounts.
the connected account is an express one which we use for separate transfers and invoices

summer valley
#

let me check that but please give me a couple of minutes and will be right back

summer valley
#

all the objects/events that are generated from that session are linked to the connected account

#

oh now I see the problem! 😦 my bad it took me a while to see the main issue

#

you have webhook endpoints on your own account but all of them are disabled

snow kite
#

ah, so i have to activate two webhook endpoints. - both on the same URI on our site?

summer valley
#

but it is disabled

#

normally we don't recommend using the same URL for own account and connect account webhooks

#

the reason is that the webhook endpoint secret might change and the Stripe instance that you want to create doesn't need the extra Stripe-Account header to fetch the connect account objects

snow kite
#

ok, thank you for your explanation. i'll test it. can i respond on this chat if there is still a problem? because i still don't have a satisfying mental model for what you explained.

summer valley
#

yes sure no worries

#

I can further explain it if you want

snow kite
#

what do you mean with "the stripe instance" we create?

summer valley
snow kite
#

ok, i think i understand:

  • to post to api endpoints and reseive webhook events on the platform account i use that endpoint and signing secret for event verification.
  • to post to api endpoints and reseive webhook events on the connected account i use that endpoint and signing secret for that webhook.

so for the separate charge and transfer scenario we aim at, the API integration and event notification flow has to look as follows:

(1) create checkout session, payment intends, ... and respond to corresponding events on the plattform account side
(2) watch out for charge/checkout succeded events on the plattform side and create a transfer to the connected account (part of the purchase belongs to the connected account)
(3) wait for transfer succeded events on the "connected" webhook side to initiate invoice creation on the plattform side
(4) look for invoice finalized events on the "platform" webhook side to set the invoice as paid and initiate invoice mail delivery.

right?

summer valley
#

the first part of your message is true

#

I'm having some trouble understanding the steps though

snow kite
#

our customers pay within one single stripe checkout session for cartitems from us (the platform side) and for items "from one else" (the connected account).

only the purchased connected account items have to
(1) show up on the invoice and
(2) the amount payed for them must be transfered to the connected account.

#

we'ld prefer invoicing also to happen on the connected account side if that's possible. - currently invoicing happens on the platform side.

summer valley
#

you can choose to create a destination charge and get your share of the payment via application_fee_amount

snow kite
#

so the destination charge would have included the sum of the items sold from the platform side.

summer valley
summer valley
snow kite
#

i think i understand. so destination charges seams to be an easier to implement, "straight forward" way to solve our problem - but the prefiously outlined way above for separate charges and transfers would also be a viable solution, wouldn't it?

summer valley
#

but you would have to create the invoices on your own

snow kite
#

yes manualy via api calls.
so i understand invoice creation with destination charges is "possible". can we invoke a checkout session for destination charges and also tell the api to create and send invoices?

this would indeed be a very downstriped way to get to our goal.

dawn kayak
#

Hi! I'm taking over this thread.

snow kite
#

hi @dawn kayak
thx @summer valley

#

ok i can try that.
but still the cart items for products from both sides (platform soled and connected account soled) must be listed on the checkout session and only the lineitems for products from the connected account must be on the invoice.

dawn kayak
#

With my suggestions above, the invoice will contain exactly the same item as in the Checkout Session. If that's not what you want, then you'll need to generate the invoice yourself.

snow kite
#

ok, i see. so the way i outlined above must be followed, resulting in API and webook integration on the platform as well as the connected account side. right?

dawn kayak
#

Can you summarize this in a new message? The thread is quite long to follow.

snow kite
#

shure:

(1) create checkout session, payment intends, ... and respond to corresponding events on the plattform account side
(2) watch out for charge/checkout succeded events on the plattform side and create a transfer to the connected account (part of the purchase belongs to the connected account)
(3) wait for transfer succeded events on the "connected" webhook side to initiate invoice creation on the plattform side
(4) look for invoice finalized events on the "platform" webhook side to set the invoice as paid and initiate invoice mail delivery.

dawn kayak
#

(1) create checkout session, payment intends,
If you create a Checkout Session, the PaymentIntent will be automatically created for you
and create a transfer to the connected account
If you use Destination Charges the transfer is done automatically for you

snow kite
#

yes, but using destination charges would result in invoice with lineitems for products we sell from the platform account as well as the connected account side which we do not want.

#

so we have to use "separate charges and transfers", don't we?

dawn kayak
#

If I understand correctly, you want the end customer to pay once for products that belong to both the platform and the connected account? And then you want to create one invoice only for the items that belong to the connected account?

snow kite
#

yes. exactly.

#

our ERP already creates invoices for products from our (platform) side and we can't do that invoicing within stripe.

dawn kayak
#

And how do you want to collect the payment? Checkout Session?

snow kite
#

checkout session.

#

(of course for the total amount)

dawn kayak
#

And there will be a single Connected account involved in the transaction? Or can there be multiple?

snow kite
#

currently only one. we need it because there must be a separate bank account behind.

dawn kayak
#

Then Checkout Session with Destination Charges should work. And then it's up to you to manually create an invoice for the connected account (and mark it paid out of bounds).

snow kite
#

ok i understand. but that would me only release of transfering the amout for the connected account products to that account on my own.

dawn kayak
#

If you want to manually send the amount to the connected account, then yes use Separate Charges & Transfers.

snow kite
#

what other problems would the destination charges way solve?
would it also solve the problem of insufficient funds errors. since the platform account shouldn't run out of funds.

dawn kayak
#

what other problems would the destination charges way solve?
It's just simpler to use, since you don't have to do the transfer yourself.

#

would it also solve the problem of insufficient funds errors.
What do you mean exactly?

snow kite
#

currently after initiating the transfer of the connected account part of the paid event (after checkout/charge succeeded event), we get back the insufficient funds error, so the transfer is stopped.

#

the transfer only works when a collegue of mine (tops up/) pays with a special crafted creadit card on the test environment: 4000 0000 0000 0077

dawn kayak
snow kite
#

yes i already tried that too. but i wasn't able to set the correct source. how can i get that ID?

dawn kayak
#

the source is the Charge ID. If you have a Checkout Session, it should contain a PaymentIntent which contains the Charge object.

snow kite
#

@dawn kayak - many, many thx to you and your collegue. i'll try that first with the separate charge and transfer way. 💜