horizontwo/policyflow PR #76 — Enforce Snapsheet approval before payment — PR #76
horizontwo/policyflow · pull request #76 ·
Transcript
PlainEnglish
Let's walk through pull request seventy-six. This change closes a gap in the payment workflow by making sure vendors are approved in Snapsheet before we let them receive payments.
PlainEnglish
This PR has two primary goals. First, enforce Snapsheet approval status as a payment prerequisite. Second, decouple verification status from bank setup completion. We're also surfacing approval warnings in the UI, blocking vendor setup for unapproved vendors, exposing the approval status through the API, and re-enabling balance validation in the payment form.
PlainEnglish
Before this change, there was a pending vendor bug. When a vendor set up their bank account, the system automatically marked them as verified and allowed payments, even if that vendor hadn't been approved in Snapsheet yet. This PR fixes that by making Snapsheet approval the authoritative gate, enforced at the UI, the form, and the server.
Architecture
The change touches five files across the stack. We've updated the payee API endpoint, the payment form and vendor setup modal in the UI, and two service modules that handle payee management and payment creation.
Architecture
Here's the authoritative gate. In the payment service, right after we fetch the payee record, we now check if their Snapsheet approval status is APPROVED. If it's not, we throw an error and reject the payment creation request. This is the final enforcement layer that makes sure no payment slips through, even if a client bypasses the UI.
Architecture
In the payee service, we changed how verification status gets set. It used to be unconditional — just setting VERIFIED whenever a bank account was configured. Now it's conditional on the vendor's approval status in Snapsheet. Approved vendors get VERIFIED, unapproved vendors stay UNVERIFIED. This decouples bank setup from payment eligibility.
Architecture
In the payment form, we added snapsheetApprovalStatus to the Payee interface, then wired it into the canSubmit condition alongside the other checks like bank account and amount validation. Notice we also restored the balance check that was previously disabled for testing. When the approval status isn't APPROVED, we show a warning message explaining that the payment can't proceed until the vendor is approved in Snapsheet.
Architecture
Over in the vendor setup modal, we check the vendor's approval status right at the top. If the vendor isn't approved, we replace the entire setup flow with a simple message and a close button. This prevents users from even entering bank details for a vendor that hasn't been approved in Snapsheet yet.
PlainEnglish
After this PR lands, the system enforces Snapsheet approval at three layers. The UI prevents entering vendor setup for unapproved vendors. The payment form disables the submit button with a warning. And the server rejects payment creation if the approval status isn't APPROVED. Together, these make sure no payment goes through without the right approval.
CodeQuality
Let's look at the risks. There are three concerns here, plotted by impact and likelihood. The top-right quadrant is where we'd want to address things first. The verification status inconsistency with snapsheet sync and the balance validation re-enabled without test coverage both land in moderate territory. The inconsistent warning color schemes are lower impact.
CodeQuality
The balance validation check was previously commented out, likely for testing purposes. This PR restores it, but there's no test coverage validating this re-enablement. If this check gets accidentally disabled again, there's a risk of silent regression where payments could exceed available balance.
CodeQuality
The verification status logic here is now conditional on approval status, but there may be other code paths in the snapsheet sync service that still set VERIFIED unconditionally during initial vendor sync. If a vendor's approval status changes after the initial sync, you could end up with inconsistent verification state across different entry points.
PlainEnglish
That's pull request seventy-six. It's a focused fix that closes the pending vendor bug by making Snapsheet approval a hard requirement before any payment can go through. The enforcement happens at three layers, and the verification status is now conditional instead of automatic. There are a few notes to keep in mind around test coverage and sync consistency, but the core gate is solid.
How this was made
Lenzon read horizontwo/policyflow at pull request #76 and generated this walkthrough automatically. The narration above is the transcript of what it says.
Explain a pull request from your own repo
Point Lenzon at a repo or a pull request and get a narrated walkthrough like this one.
Try it