We need to store the Stripe key on the journal payment of type “Stripe”.
We need also to store if needed the Customer to be able to make recurring charge without asking credit card each time. This will be stored on a new Model
account.payment.stripe.customer (similar to SEPA mandate). If the record can not be deleted but instead it will be inactivated. In this case, it will be deleted on Stripe and the key will be erased periodically by a cron task.
We need a way to retrieve token for a payment if we do not have a Customer key. This process to not require PCI DSS will need to happen in the browser of the user. For that, we should deliver at an URL a minimal web page which display the Checkout form and retrieve the posted data. To ensure this form will only be used by allowed user, we will use a token in the form that will be generated by payment.
The same work-flow will be implemented for the Customer registration (but without any amount).
Of course this checkout method could completely be skipped in favour of a custom website implementation. The purpose of this checkout from client is for telemarketer or POS.
Tryton payments are processed by group but Strip API process one payment per post. So we need to desynchronise the Tryton processing and the post to get transactional integrity. A cron task will post charge for all Stripe payments which are in the state processing (using a generated UUID for idempotents). The Charge request will use the token stored on the payment or the Customer id. If the charge succeed then the payment is passed to succeeded also. If the charge fails depending on the error, the payment will be failed (card_error ) or retried later (technical issue).
- Add support for refund
- Manage dispute via web-hooks
- Add ACH support
- Manage payment methods