This is some documentation to describe the issues that we are faced with while implementing our integration with stripe.
We want to use their PaymentIntents Api.
We want our customers to be able to register their card at any time, and then have that card be used to charge them for their parkings during the next invoicing period. This will mean that we want our customers to authenticate their card with 3D secure, while they are regestering the card. So that we can get applied for an SCA exemption while performing all fututre charges for that card. If we get the initial 3Ds auth, it will mean that our customer will most likely (The banks can reject our exemption requests at any time, but it is not hugely likely) not have to authenticate with 3Ds for future charges.
The problem is that stripe does not have any support for doing a 3Ds auth outside of a transaction at the moment (According to docs, this should be implemented in July 2019).
-
Change our flow so that we can use for example the billing service in stripe. Stripe will then handle all the 3Ds things for us. This is not really feasible since it would require us to rebuild a whole lot of how we perform card transactions. And it is not the service that we have bargained for with stripe.
-
Register cards without preparing the 3Ds auth, and handle the authentication requirements once we perform an actual charge during our invoicing. This is probably a way that will cause our customers a lot of confusion and may lead to us having transactions that fail. Note we will want to support this anyway at some point, since the banks can reject our exempt requests at any time, and if they do, we want to be able to handle the situation automatically.
-
Perform a dummy transaction when we register the card, and repay the amount immidietly, just so that we trigger 3Ds This method is something that the people at Stripe recommended that we should not do. Because the card networks do not like dummy transactions. It is unclear what the consequences may be, and what the risk is that we will get punished for the dummy transactions.
We will also be able to stop doing these dummy transactions, once Stripe release the feature that allows us to trigger 3Ds outside a transactions.
As it is with our integration with dibs at the moment, we redirect our customers to a page that dibs handles for registering the card. This page handles both the registration and the authentication via 3D secure. As far as we have been able to tell, they achive this by performing a mini-transaction that triggers 3D secure, and then cancel or refund the payment.
+------------------------------+
| |
| |
| Customer wants to add card |
| |
| |
+---------------+--------------+
|
v
+-----------+-----------+
| |
| Customer inputs email |
| and clicks add card |
| |
+-----------+-----------+
|
v
+--------+---------+
| |
| Redirect to DIBS |
| |
+--------+---------+
|
v
+------------+-------------+
| |
| 3D secure authentication |
| |
+------------+-------------+
|
v
+------------+-------------+ +-------------------------------+
| | | |
| Redirect back to smspark +----->+ Callback to system on success |
| | | |
+-----------+--------------+ +-------------------------------+
|
+-------+--------+
| |
v v
+-----+-----+ +------+-------+
| | | |
| Fail page | | Success page |
| | | |
+-----------+ +--------------+