This is a very simple first stab at introducing Stripe in the backend, receiving a token from the front end.
Initially we thought we could be able to avoid using JavaScript and do all the payment handling from the server. However that would make PCI compliance more strict, so we changed our minds.
In addition, Radar, which is Stripe's integrated solution for automatic fraud protection, only supports integrations that make use of client-side tokenization.
The description field is optional but was added as a fast an easy way to include donor email. It was
a requirement from one of our offices to display the email of the donor so that they can more easily scan the payments in Stripe.
Regarding the validation, for now it justs validates presence of fields (i.e., they are not null).
Coverage remained the same at 100.0% when pulling ef095dec1d6c00a528ef0a72f91204d4bf4867cc on stripe-extraction into 14f9e5ca7429b65791113c4d540f5c6c07a0e53a on master.
This is a very simple first stab at introducing Stripe in the backend, receiving a token from the front end. Initially we thought we could be able to avoid using JavaScript and do all the payment handling from the server. However that would make PCI compliance more strict, so we changed our minds.
In addition, Radar, which is Stripe's integrated solution for automatic fraud protection, only supports integrations that make use of client-side tokenization.
Test values and tokens taken from the API docs:
https://stripe.com/docs/testing
and
https://stripe.com/docs/api/ruby#error_handling
The description field is optional but was added as a fast an easy way to include donor email. It was a requirement from one of our offices to display the email of the donor so that they can more easily scan the payments in Stripe.
Regarding the validation, for now it justs validates presence of fields (i.e., they are not null).