#mhenrixon-webhooks

1 messages · Page 1 of 1 (latest)

north scaffold
#

you should probably listen to the payment_intent.succeeded event and account.updated events, at a minimum

tribal dew
#

And if I wanted to do better than minimum?

north scaffold
#

what I mean by "at a minimum" is just that I don't have a ton of context on what you're trying to do / what events your application might find useful

#

not that more events is necessarily better

tribal dew
#

So one user pays another user for their time. They meet, we charge a fee for the service and eventually release the payment to the receiver unless there are any complaints and both people agree that the meeting took place.

north scaffold
#

payment_intent.succeeded is useful for processing any logic after the payment succeeds (even if you have logic that redirects the client after the payment succeeds, it's useful to have webhooks as a backstop in case the client blows up)

tribal dew
#

So if the payer disputes the charge for example that would be interesting but I am also looking to keep the number of events down to a minimum.

north scaffold
#

and account.updated is needed to keep track of any changes in the connected account's ability to accept charges, make payouts, etc.

#

what you want to do with account.updated varies a bit depending on which account type you're using

tribal dew
#

express

#

I am mostly looking for charges and transfers to be enabled but I guess also for the account to be deactivated

#
account = Stripe::Account.create({
          country: user.country_code,
          email: user.email,
          type: "express",
          capabilities: {
            card_payments: { requested: true },
            transfers: { requested: true }
          }
        })
#

Then in the webhook handler:

def update_charges_enabled_at
        if event.data.object.charge_enabled
          stripe_connect_account.charges_enabled_at ||= Time.current
        else
          stripe_connect_account.charges_enabled_at &&= nil
        end
      end

      def update_payouts_enabled_at
        if event.data.object.payouts_enabled
          stripe_connect_account.payouts_enabled_at ||= Time.current
        else
          stripe_connect_account.payouts_enabled_at &&= nil
        end
      end
#

Anything else that might be interesting for an express account?

#

I am not looking to cover everything but I want to make sure I cover the basics. The problem I have had in the past is that things get out of sync.

north scaffold
#

it depends what other information you're denormalizing from the account resource into your own db, but generally you want to know if the account can make charges (so you can eg: stop directing buyers to it on your app if so)

#

generally speaking, stripe will handle onboarding for express accounts, but you might want to put a pointer to the onboarding state in your own ui

tribal dew
#

Anything in checkout.session.completed and checkout.session.async_payment_succeeded that might be of interest?

tribal dew
north scaffold
#

that depends what sort of payment methods you support

#

if you only support sync payment methods (eg: card payments), then you don't need to worry about async success

tribal dew
#

I mean, we only really require card payments and from what I could tell that includes apple pay etc?

north scaffold
#

yeah, that's sync

#

tbc, if you're using checkout exclusively, checkout.session.completed & payment_intent.succeeded are essentially interchangeable

tribal dew
#

Checkout.session.completed is less relevant that payment_intent.succeeded in our case anyway right?

north scaffold
#

you only need to listen to one of them

tribal dew
#

Perfect! This is exactly the type of advise I was looking for

#

So basically (unless I want to handle disputes, refunds etc) payment_intent.succeeded and account.updated should suffice

#

Thanks a lot for being available on a Sunday 🙂

north scaffold
#

probably also account.application.deauthorized
if you're using express

#

np!