Re: [bitfolk] Volunteers sought to help test out Stripe cont…

Top Page
Author: Andy Smith
Date:  
To: users
Subject: Re: [bitfolk] Volunteers sought to help test out Stripe continuous credit card authority

Reply to this message
gpg: Signature made Tue Jan 11 23:26:04 2022 UTC
gpg: using DSA key 0E4236CB52951E14536066222099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hi Chris,

On Tue, Jan 11, 2022 at 11:06:22PM +0000, Chris wrote:
> Happy to volunteer testing Stripe


Great! You will need to add some card details in the panel at:

    https://panel.bitfolk.com/account/billing/


Though unless you let me know off-list that you are willing to have
an early renewal, nothing further will happen until it's your renewal
time.

> Additionally some learnings from implementing Stripe subscriptions & ad-hock charging using Stripe "connect" which has been running for a while now:
>
>
> - yes the postcode can be anything, but may result in "do_not_honor" payment failures in live mode


We do already have one-off card payments since 2013; they just
redirect to Stripe's Checkout.js to do everything. Probably some of
them have had postcode check failures and I just haven't noticed.

I might have to care more about that for offline charging as if one
of those charges fails we have to contact the customer and get them
to re-submit the details etc. which is a bit of a hassle. Might end
up having to be strict about it at the point of card addition. And
if so, would rather that Stripe handled that if possible.

As it is this implementation won't use subscriptions, only a
SetupIntent for arbitrary future charges.

> - getting familiar with the automated payment retry behaviour, which is very useful but can be confusing for a customer since the retries "use machine learning to choose best retry day". At attempt to add visibility of payment retry is here:
> https://github.com/Subscribie/subscribie/issues/683#issuecomment-1003793965


Not sure if that will apply to arbitrary charges outside of a
subscription. I set the PaymentIntent to require immediate
confirmation so it will be interesting to see what kinds of failure
codes are returned (I have tested the usual declined codes using the
test card numbers).

> Hope the above is useful


Yep, thanks!

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting