#DeputyCheese-SOFORT
1 messages · Page 1 of 1 (latest)
Hi there, the client-side polling makes sense if the payment can be confirmed immediately. Since SOFORT confirmation requires a much longer time, I don't think it's practical to implement polling, as the doc suggested
Be aware that some types of Sources take minutes (or even days) to become chargeable. If you decide to poll the Source, we recommend that you time out at some point and tell the customer that their order is awaiting payment confirmation, then send them a payment confirmation email asynchronously. You can see our recommended customer-facing messaging for each Source status in the table below.
Thanks for the answer
So, would this be a good implementation: 1.) user finalizes his order and I try Source::retrieve. If it's chargeable I charge via Charge::create 2.) if it's not chargeable I am running a cronjob in the background who tries to Source:retrieve it until it's chargeable and then charge it via Charge::create ?
- If you are not maintaining legacy code I'll highly suggest using to the PaymentMethod/PaymentIntent API.
- You should listen to the webhook events instead of managing the cronjob by yourself.
1.) Atm we cannot change that implementation.
2.) Why is that? Webhooks seem to be a bit confusing and hard to test tbh
Running cronjob would easy hit the API rate limit when you have more customers.
I won't deny that webhook requires a bit learning curve, but it would benefit you in the long run.