#BrianC-ach-delay

1 messages · Page 1 of 1 (latest)

silver dagger
#

Hi there! I think this is what you're looking for: https://stripe.com/docs/payments/ach-debit#timing

Balance Transactions are generated if and only if money is moved, regardless of creation events, so I wouldn't rely on creation time for getting them

grand gate
#

Thanks! Hmmmm. This may not be it. If it is, it may be problematic as test behaviour giving false impression of results. According to your statement and the docs a balance transaction object would technically not be available for 2 days. When testing is is available literally 2 seconds later as we retry and it sends it after the failure.

#

i would assume that test accounts behave exactly like live accounts but with test data. Can you confirm? I think we may be talking about two different things - business implentation timimg and API respoinse timing

silver dagger
#

I think it's intend to be" may not be available for up to 2 days". The timing is variable with an upper bound of either 4 business days or 2 business days.

grand gate
#

Are you 100% sure? It makes it very difficult to test.

#

It would then be 2 seconds to 4 days range trechnically

silver dagger
#

i would assume that test accounts behave exactly like live accounts but with test data. Can you confirm? I think we may be talking about two different things - business implentation timimg and API respoinse timing
Testing is a little harder with the delayed payment methods, simply because we don't simulate the same random variability, so unfortunately it is difficult to test by default. I would recommend leaning heavily on webhooks in this case and just make sure your handler is set up to listen for the payment events as they come in.

grand gate
#

OK. Got it. That should be made clear somewhwere in the docs though. We should be able to assume that adding another payment method would not introduce a hard to debug error into our code. We utilize both immediate access and webhooks currently.

#

Just our 2 cents

silver dagger
#

That's a totally valid callout. Most of our docs have an entire webhook section toward the end of the guide in order to close the loop on integration specifics, so I'm actually surprised to see that these don't

grand gate
#

Thanks for your help

silver dagger
#

Sure thing! Let us know if you run into any other speedbumps

grand gate
#

One last thing and hopefully this will demonstrate why this could be disastrous if not addressed in docs. When testing locally, we get no error most likely because there is a slight network delay. On our test server there we get the error (null balance transaction object) because the hetwork connection is super fast and most likely hits the Stripe server back almost instantanously. We would not have noticed this if we had a slower network on our stage server (or even our production server). so technically this could have gone all the way to production (if our production servers were not on a super fast network) so it could hae gone unnoticed. Then one day, we decide to upgrade the network and all ACH debit transactions updating purchases in our database fail. Simply because of a faster network connection. Just saying. It's something that should be made very clear to devs who may or may not have experience with it and have decided to do a simple implementation without a webhook. Hope that helps.

#

By made clear I mean the variance in behavoir of tha availaiblity of the balance transaction opbject for delyaed payments between test and live accounts

silver dagger
#

I was actually just typing up this feedback to the product team!