#Maxv
humble seal
Do you have the ID of a payment.created event that you got when listening to all events? I was not aware of that event myself.
humble seal
Thank you, checking in to that event
Still looking in to this. I think I will need to pull in a colleague and will get back to you with what I can find.
dusky ridge
got it, this event is in test env
humble seal
Yep yep, I can see it being created from the transfer that you are creating though I thought there would be other events on the connected account related to this flow
The assumption may be that because your system is creating the transfer it doesn't need to be notified of the creation via a webhook
hexed cove
Hi there 👋 jumping in.
dusky ridge
Hello!
hexed cove
payment.created is not a documented Event type, it's more of a placeholder to represent the outcome when a Transfer is created on your Platform account that moves funds to the Connected Account.
It sounds like you're working with either a Destination Charges flow or a Separate Charges and Transfers flow. With those approaches you will largely want to focus on Events emitted by your Platform account rather than those generated for the Connected Accounts. Can you tell me a bit more about what you're hoping to track by listening for Events?
summer mossBOT
dusky ridge
Yeah, im using the payment.created event in order to find out when a payment was created from our platform to the connected account so it it fails we can send a specific email that says that the funds will be withdrawn form the connected account.
I know that I can also to the charge.transfer.source_transaction route but I though that waiting for the event could be better without calling for more objects from stripe
hexed cove
I don't think you will want to listen for the payment.created Event, but I'm still not quite sure what you're hoping to accomplish by listening to it, so let's talk a bit more about the specifics of the flow that you're building. You mentioned sending an email to notify the Connected Account that funds will be withdrawn, but if the Transfer wasn't created successfully then funds will not have been moved to the Connected Account yet to be withdrawn.
Are you using a Separate Charges and Transfers flow, where your code creates a Transfer object to move funds from your Platform account to your Connected Account?
dusky ridge
Yeah we are using it for ACH Transfers, so we have a case when we are moving funds to the connected account before the Bank trinsfer finilizes
hexed cove
Gotcha, payment.created Events on the Connected Accounts are not what you're looking for then (those will be created when you create the Transfer object to move funds to the Connected Account).
I would advise waiting for the funds to become available before moving them to the Connected Account or using the source_transaction parameter when creating the Transfer, but if you want to preemptively move those funds you will then need to monitor Events from the Platform to know if the payment proceeded as expected.
To clarify (because they have different flows), when you mention ACH Transfers, are you referring to ACH Credit Transfers:
https://stripe.com/docs/sources/ach-credit-transfer
ACH Direct Debits:
https://stripe.com/docs/payments/ach-debit/accept-a-payment
or our newer Bank Transfer flow?
https://stripe.com/docs/payments/bank-transfers/accept-a-payment?country=US
dusky ridge
The never Bank Transfer flow:
https://stripe.com/docs/payments/bank-transfers/accept-a-payment?country=US
hexed cove
Gotcha, so with that you will want to listen for Events on the Platform account. payment_intent.succeeded would be a good option if you're using this for one-off Payment Intents, and invoice.paid may be a better option if you're using Bank Transfers to pay for Invoices.
One hangup though, is that those Events indicate success. I don't believe Bank Transfers (because they're a push-based payment method) have timeouts the way Direct Debits (pull-based payment methods) do. So I don't believe there are good Events to listen to that would give you a definitive indication over whether a payment failed.
dusky ridge
hmm what do you mean?
There is charge.failed in case that the ACH payment failed
hexed cove
charge.failed Events are emitted when Charges fail, which is something that happens for pull-based payment methods such as cards or ACH Direct Debits. In those flows Stripe makes a request to pull funds, so we know when that pull fails and can notify you about that failure.
Push-based payment methods, such as Bank Transfers, don't behave the same way so we have less insight into them. With push-based flows the customer controls when they send funds, and how much they send. This makes it harder for us to decide when something has "failed" and instead you will need to add your own logic to categorize and handle failures. The customer can send the funds to us at any time, it doesn't have to happen right away, so we don't know how long to wait before considering a payment to have failed. Similarly the customer controls the amount they send, so we don't know whether one payment without enough funds means the overall payment should fail or if additional funds are expected to be received later.
dusky ridge
Hmm maybe I made a mistake with the type of ACH.
example of a Payment Intent:
pi_3NeyggFdCE6n8elI01dcnWOB
hexed cove
Ah, yeah, that seems to be using ACH Direct Debit. In which case you want to listen for payment_intent.succeeded or payment_intent.payment_failed Events on the Platform account to be notified about whether the payment completed successfully.