sz

[sterile loom]

Yes, there'll be an account field if you've correctly configured the webhook to receive events from connected accounts: https://stripe.com/docs/stripe-apps/build-backend#receive-events

[strange stream]

Thanks, I have another question, the goal of this stripe app is to implement a credit based usage system. Just wanted to double check before I go any further, does stripe already provide this functionality natively?

[sterile loom]

Sort of yes: https://stripe.com/docs/invoicing/customer/balance

[strange stream]

I see, thanks

[sterile loom]

Let me know if you've any other questions

[strange stream]

I can see from the docs that it mentions that the account field will be present for publicly listed apps

But the account field doesn't show up when testing the endpoint locally.

Is there a way to access the account field in localhost?

[sterile loom]

I think you need to install the app on a different account via https://stripe.com/docs/stripe-apps/test-app

Let me know if that works

[strange stream]

I think the main issue was that the --stripe-account flag wasn't being used.

But now instead of using stripe listen --forward-to localhost:8787/webhook I'm serving the webhook via stripe listen --forward-connect-to localhost:8787/webhook and my localhost server isn't picking up the post requests anymore

[sterile loom]

--forward-connect-to is redundant, --forward-to covers Connect usage by default

I think the main issue was that the --stripe-account flag wasn't being used.
Yeah I mean that's needed via the CLI, but I assumed you were just testing normal usage of your app and wanting associated events to fire

[strange stream]

I've strictly just been testing through the CLI as of now

but, I'll try testing through normal means and see if that provides better results

[sterile loom]

The port issue is likely unrelated to anything in the CLI. What's the error if any?

[strange stream]

There isn't, the requests aren't going through when using forward-connect-to and if forward-to is used instead, the account field isn't included

Also the document that you sent to test the app externally, it states that the app has to be in public distribution mode

but doesn't doing that fully release the app? Or does still get contained in test mode?

[sterile loom]

No it won't be publicly distrbuted until you actually publish it

[sterile loom]

Not sure what's happening there. Sounds like some kiund of configuration issue at your end?

[strange stream]

This is my current manifest

{
  "id": "com.example.creditsystem",
  "version": "0.0.3",
  "name": "Creditsystem",
  "icon": "",
  "permissions": [
    {
      "permission": "event_read",
      "purpose": "Allows reading event data from users who have installed the app"
    },
    {
      "permission": "checkout_session_read",
      "purpose": "Fulfills the credits for the user after a successful purchase"
    }
  ],
  "ui_extension": {
    "views": [
      {
        "viewport": "stripe.dashboard.customer.detail",
        "component": "App"
      }
    ],
    "content_security_policy": {
      "connect-src": null,
      "image-src": null,
      "purpose": ""
    }
  },
  "distribution_type": "public"
}

[sterile loom]

No I mean specific to your webhook endpoint

The app manifest is likely unrelated to the CLI/event issue

[strange stream]

The requests actually started to go through once I change it from "private" to "public"

But now that I'm trying to test the app with a different account, I'm getting an error saying that the app doesn't have the righ permissions and would be resolved if it had the read_write scope

[sterile loom]

What's the full error?

[strange stream]

I was able to resolve it by logging into the different account on the cli. But even then, even when calling the webhook from a different account, it still doesn't show the account field

I'll just test it manually by going through a checkout, see if that works out

[sterile loom]

No, you shouldn't do that

You need to be signed into the CLI as the platform account (the one that builds, owns the app)

[strange stream]

I see

[sterile loom]

That account field is only included in the payload if the event is sent to a Connect webhook: https://stripe.com/docs/connect/webhooks

[strange stream]

I got the following error when trying to trigger the endpoint from the different account (the one that didn't create the app)

Trigger failed: Request failed, status=403, body={
  "error": {
    "code": "more_permissions_required_for_application",
    "message": "This application does not have the required permissions for this endpoint on account 'acct_1ObLBEJVArmNjTxQ'. Having the 'read_write' scope would allow this request to continue.",
    "request_log_url": "https://dashboard.stripe.com/acct_1ObLBEJVArmNjTxQ/test/logs/req_eSaawNGSwDYW4u?t=1705922277",
    "type": "invalid_request_error"
  }
}

These are the steps I took

1. stripe login (login to the account that created the app)
2. stripe listen --forward-to localhost:8787/webhook
3. stripe trigger checkout.session.completed --stripe-account acct_1ObLBEJVArmNjTxQ

[sterile loom]

Is acct_1ObLBEJVArmNjTxQ actually connected to the the platform account?

(have you installed the app on acct_1ObLBEJVArmNjTxQ)

You can't just make API requests (which is essentially what the trigger command does) on another account unless there's a 'connection' established, which is done via the app installation

[strange stream]

Just to confirm, installing the app is a matter of going to the external test link. In my case it would be https://dashboard.stripe.com/apps/install/channellink*AY0w0HwACQAAACN3%23EhcKFWFjY3RfMUhwUzhSTDFXa3NRdnhaW

Then selecting the appropriate test account (the account associated to acct_1ObLBEJVArmNjTxQ)
and then installing

if this is the case, the app should be installed on the test account

[sterile loom]

Oh, your manifest doesn't have checkout_session_write permission: https://stripe.com/docs/stripe-apps/reference/permissions

So the error is write you can't use that trigger command as you're trying to create a Checkout Session

Update the manifest, accept new permissions on the installation and then CLI should work

Probably going to need a lot more permissions actually

Because that trigger uses other endpoints/objects: https://github.com/stripe/stripe-cli/blob/master/pkg/fixtures/triggers/checkout.session.completed.json

So 2 options:

• Add product_write, price_write permissions
• Use the --override flag in trigger command to use existing price_xxx object on the account: https://stripe.com/docs/cli/trigger#trigger-override

[strange stream]

when the app goes live, it wouldn't need the product_write and price_write permissions since it should only be listening for the checkout_session_complete event right?

[sterile loom]

Yes, exactly. So with that in mind the 2nd option above is probably a more realistic reflection of your working app to test with

Another option is to just have 2 CLI instances: one authenticated as the platform that listens and forwards for the event, the other as the connected account that triggers the event

Agree that this is pretty messy today

[strange stream]

If I'm understanding this correctly:

CLI 1

1. stripe login (login to the account that created the app)
2. stripe listen --forward-connect-to http://localhost:8787/webhook

CLI 2

1. stripe login (login to the account that DIDN'T create the app)
2. stripe trigger checkout.session.completed --stripe-account acct_1ObLBEJVArmNjTxQ

[sterile loom]

Yes, but the --stripe-account flag would be redundant

I don't even know if you can auth multiple CLI sessions like that for different accounts though

[strange stream]

Just tried, account still didn't show up, I'll try the --overide flag in trigger

[sterile loom]

Can you share the evt_xxx ID?

[strange stream]

mb, wrong one

https://dashboard.stripe.com/acct_1ObLBEJVArmNjTxQ/test/events/evt_1ObM25JVArmNjTxQ4dHJL9sU

evt_1ObM25JVArmNjTxQ4dHJL9sU

[sterile loom]

To confirm, you received the event at the endpoint?

I can see a version we delivered to the CLI somewhere that included the account field

But looks like you have 4 CLI instances active?

[strange stream]

yes, the event went through

I just restarted my computer, so there shouldn't be 4 CLI instances anymore

I tried again just now and the event went through, but the account field was not present

here's the code that I'm using to pick up the events

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object;
    console.log("session: ", session)
    // TODO: Fulfill the credits
  }

[sterile loom]

evt_xxx ID please

[strange stream]

I'm so dumb

I just realized the issue

I was console logging the event.data.object

[sterile loom]

Wait, account isn;'t in the data hash

[strange stream]

the account is in event

[sterile loom]

It's a top-level field

AHA

[strange stream]

wow

thanks for having the patience to go through this with me

[sterile loom]

Of course - glad we got there in the end

[strange stream]

yes, that's what matter most in the end

alright, thanks again, going to sign off here

[sterile loom]

np! 🫡