#knuppi-connect-flows

1 messages · Page 1 of 1 (latest)

visual perchBOT
rain escarp
#

Looking at the event, all the endpoints are responding with 200
including the 2 CLI sessions

visual perchBOT
wary pebble
#

This says 408

#

@rain escarp where do you see that there are two CLI sessions?

rain escarp
#

In logs on our end

wary pebble
#

On the page I'm looking at, I see that my CLI replies with 408 (as intended), however I can't make Stripe to retry the webhook

#

Is it possible to make Stripe to do the retry?

rain escarp
marsh imp
wary pebble
#

OK, I see.
The reason why I want to do this is because the customer.subscription.created webhook is sent before the checkout.session.completed.

marsh imp
#

Event order isn't guaranteed at all

#

That's covered in our docs

#

They could come in any order

wary pebble
#

I need checkout.session.completed to set up the accounts on our servers, but we also want to save the payments which are available in customer.subscription.*

#

Event order isn't guaranteed at all

Yes, I know. That's why we want to trigger a retry by replying with 408

#
2024-01-11 15:51:57   --> customer.subscription.created [evt_1OXPbrDCZJ2TeDMZbP7pzNJW]
2024-01-11 15:51:57  <--  [408] POST http://127.0.0.1:80/app/payments/stripe-webhook/sg/ [evt_1OXPbrDCZJ2TeDMZbP7pzNJW]
2024-01-11 15:51:57   --> customer.subscription.updated [evt_1OXPbrDCZJ2TeDMZ3WYEqazo]
2024-01-11 15:51:57   --> payment_intent.succeeded [evt_3OXPboDCZJ2TeDMZ1w9Q0jBO]
2024-01-11 15:51:57  <--  [408] POST http://127.0.0.1:80/app/payments/stripe-webhook/sg/ [evt_1OXPbrDCZJ2TeDMZ3WYEqazo]
2024-01-11 15:51:57  <--  [200] POST http://127.0.0.1:80/app/payments/stripe-webhook/sg/ [evt_3OXPboDCZJ2TeDMZ1w9Q0jBO]

@rain escarp this is from the logs in my CLI

marsh imp
#

Hi Hanzo had to step out

#

What's the question?

wary pebble
#

I need to know what status codes are required in order to force a retry from the Stripe webhooks?
And also; is it possible to see this retry in the CLI?

marsh imp
#

Retries won't happen automatically in the cli

#

You'll need to run the command to manually retry

#

The one I shared

wary pebble
#

I see, thank you

#

Another question (if I may):

marsh imp
#

Sure

wary pebble
#

I'm currently listening to checkout.session.completed in order to create accounts for my clients.

However, it was working very well until right now; in the data received in the webhook event.data.object.invoice there's an invoice ID ("in_1OXQaUDCZJ2TeDMZOWNjd88C")
But when I tried to retrieve it, I got a 404 from Stripe

#

Question; how come you've set the invoice ID but there's no Invoice to retrieve?

#

What information can I be 100% sure of existing as the payment is finalized?

marsh imp
#

Can you share the request id where you're getting a 404?

wary pebble
#

evt_1OXQaZDCZJ2TeDMZP5abPrJz

#

When I received this webhook, I retrieve the Invoice in order to see a list of addons (additional products/prices) which the client also has paid for - and enabling those addons on our side

marsh imp
#

No request id for the 404 is what I need

#

Not event id

wary pebble
#
I0111 16:54:41 _util <stripe:123> message='Request to Stripe api' method=get path=https://api.stripe.com/v1/invoices/in_1OXQaUDCZJ2TeDMZOWNjd88C

I0111 16:54:42 _util <stripe:123> message='Stripe API response' path=https://api.stripe.com/v1/invoices/in_1OXQaUDCZJ2TeDMZOWNjd88C response_code=404

I0111 16:54:42 _util <stripe:123> error_code=resource_missing error_message="No such invoice: 'in_1OXQaUDCZJ2TeDMZOWNjd88C'" error_param=invoice error_type=invalid_request_error message='Stripe API error received'

stripe._error.InvalidRequestError: Request req_d2pi6KijzZM8Sg: No such invoice: 'in_1OXQaUDCZJ2TeDMZOWNjd88C'

Looks like req_d2pi6KijzZM8Sg is the req ID?

#

I can't find req_d2pi6KijzZM8Sg in my dashboard 😦

marsh imp
#

Oh you're using the wrong api key

#

You're retrieving the invoice on the wrong account

#

The invoice and event exist on acct_1G3JScDCZJ2TeDMZ

#

You are trying to retrieve on
acct_1MRCHrL8luXqMHtb

#

That's why request is failing and why you don't see it on the dashboard

wary pebble
#

ok, so I need to use the API_KEY for the account - not for the platform?

marsh imp
#

Neither of those look like connect accounts...

#

So use acct_1G3JScDCZJ2TeDMZ api key

wary pebble
#

This is the flow, currently:

  1. a potential customer enters their information
  2. if the form is valid, we send the customer to the Checkout redirect url
    2b. this creates a Customer in Stripe
  3. after the customer is sent back to the success_url we create an Account which we connect to the platform
marsh imp
#

Yeah but the above isn't a connect account

#

Has 0 connections

wary pebble
#

shouldn't the platform be able to retrieve the invoice created by the Customer? the Account hasn't been created yet

marsh imp
#

It should

#

But what I'm telling you is you're not retrieving it as the platform

#

That's why you don't see the request in your dashboard

#

You're using another account entirely to retrieve

wary pebble
#

you're saying that I should use the acct_XXX api_key to retrieve?

marsh imp
#

Use the one for acct_1G3JScDCZJ2TeDMZ

#

That's who created the checkout session

#

So that's where the invoice will exist as well

#

You're using an api key for acct_1MRCHrL8luXqMHtb instead

wary pebble
#

this is the test key for the platform

marsh imp
#

You're not though

#

And please never share secret keys publicly

#

Even if they're test keys

wary pebble
#

OK, noted

#

I will double-check which key is being used, 1min

marsh imp
#

You're using one ending in yc19cq

wary pebble
#

Aha!

#

Thank you for showing me the light!

#

We have multiple platform accounts, one for EU and another for the rest of the world. it complicates things

marsh imp
#

No problem

wary pebble
#

Are there any direct benefits for registering EU companies under the EU-platform?

#

Or should all companies be registered under the global entity?

visual perchBOT
wary pebble
#

hi @polar sequoia

Are there any direct benefits for registering EU companies under the EU-platform?
Or should all companies be registered under the global entity?

polar sequoia
wary pebble
#

We're a B2B2C platform

#
  • CustomerA is in Spain, with end-users typically in Spain. They create products which we sync with your API, they receive payments through our mobile app
  • CustomerB is in Singapore, with end-users around Singapore. They also create products and receive payments through our mobile app
#

Both CustomerA and CustomerB are Accounts connected to our Platform

#

We have two regions, EU and REST_OF_THE_WORLD

polar sequoia
#

What kind of connected accounts are you working with?

wary pebble
#

All connected accounts are businesses

#

My first question is; when I create CustomerA (creating the Customer is step 1, they pay for the Subscription, and upon completed payment I "convert" them into an Account) should I create them under REST_OF_THE_WORLD?

#

CustomerA is registered in Spain, and their end-users are in Spain. Will there be cross-border payout costs?

polar sequoia
#

No, I mean are the connected accounts standard? express? custom? What type of funds flow are you hoping to use with them (Direct? destination)?

wary pebble
#

Yes, Standard accounts

#

We're charging the Accounts through application_fee_amount

polar sequoia
#

And I assume you're using Direct charges (using the Stripe-Accuont header)?

wary pebble
#

Yes

#

we're setting stripe_account={{ Account.ID }}

#

I mean, we used destination charges but we recently changed this to use direct charges

polar sequoia
#

If you're using direct charges then you wouldn't have to worry about cross-border (because the merchant of record is the connected account itself).

wary pebble
#

OK, that's reassuring. So we can use our REST_OF_THE_WORLD-platform to register all companies, no matter where their place of operation actually is?

polar sequoia
#

Yes, I believe so (but definitely try this out in test mode to make sure other parts of your flow aren't implicitly relying on things being in the same region)