This lesson's interactive features are locked, please to keep using them
Financial Data
Financial data creates a direct path from disclosure to fraud. A leaked email address is bad, of course. But a leaked credit card number or bank account number is usually much, much worse.
The best solution is often to not handle card data at all. A payment provider can host the payment page, collect the card details, and tell your application whether the payment succeeded:
- The application creates a pending order with the server-calculated amount and redirects the customer to the provider.
- The provider collects and processes the card details on its own site.
- The provider sends the result to an authenticated webhook in the application.
If you're a developer at a payment provider, you have no choice but to handle card data. But many companies can and should avoid that responsibility.
Authenticate the Result
A webhook is a server-to-server request, so browser protections like CSRF checks don't authenticate it. The receiver needs to verify a secret or signature supplied by the provider before changing an order.
The payload also needs a stable identifier for the exact operation being updated. For example, match a numeric orderId in the provider's payload to an internal order ID – not to a customer email or other mutable customer data.
This boundary lets the application retain the order ID, along with the amount and the payment status, without receiving card numbers or verification codes.
Assignment
Bearly Secure already creates pending orders, redirects customers to PawPal, and has a webhook route. But it trusts every claimed approval! Authenticate and validate PawPal's result before the existing route marks an order as paid.
With Bearly Secure still running, run and submit the CLI tests from the project root.