#GiGStartr-payment-intent
inland furnace
hey.
My system uses a sign-up/pledge system, where all the "pledges" are charged together at confirmation time. I'm noticing the createPaymentIntents API endpoint pretty consistently takes just under 1.5 seconds for round-trip when confirm=auto. Is this typical?
Some minor adaptations needed if that will be consistent (time-outs on Cloud FUnctions), but not a big deal. Just looking at performance end-points Currently entirely in test mode.
(in this case, 120 in-a-row, since you don't have any concurrecy)
lost narwhal
Gotcha. Confirming a Payment Intent does add to the processing time, because the confirmation step includes actually reaching out to the corresponding payment method networks for authentication of the payment.
inland furnace
Well, yes, I assumed as much. Just making sure there isn't another bottleneck. Is there strong odds of this getting longer in Live? If so, I need to "batch" my submissions into separate Cloud Function invocations (540 seconds max)
lost narwhal
I'm looking to see if we have any guidelines on this, but we might not as the processing speed could fluctuate from one card network to another.
inland furnace
k. I'll make the Cloud Function self-monitoring - checking in between submissions to see if approaching time-out, and submitting another invocation to finish. I got it.
to be honest, it's the lack of concurrency that makes this trickier in my edge-case (and I acknowledge it's an edge-case) - combination batch charging, limited-time Cloud Functions, etc - it's very server-less setup.
all good; you can close this.