Repository navigation
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| /** Mint a one-card hosted vault link. Purchase-approval options require org.write in addition to card setup permission. */ | ||
| async createSetupLink( |
There was a problem hiding this comment.
🟡 Card approval release note omitted
When paymentCards gains these methods, no new Changeset records their release note. The pending core Changeset covers spending limits only, so the generated release omits the new helpers.
Learn more
Published packages use Changesets to generate their version updates and release notes. The existing core Changeset predates this feature and describes only spending-limit management. This PR adds public card approval and setup-link methods but adds no corresponding Changeset, so the generated release note does not describe them.
Example: When the pending core Changeset produces the next minor release, its generated entry mentions spending limits but not getPurchaseApproval or createSetupLink.
Recommended fix: Add a Changeset for @sapiom/core describing the new methods and backend rollout requirement; keep the manual unreleased changelog entry only if that is also part of the project's release process.
Was this helpful? React with 👍 or 👎 to provide feedback.
bf334d2 to
338682a
Compare
d07cbb8 to
2d272fc
Compare
1 participant
What
Expose saved-card purchase approval settings and hosted setup-link helpers through
client.paymentCards. Clients can enable or pause approval with the saved version and explicitly authorize an approval choice for the new card's hosted vault form.Why
Integrators should configure the card setting directly instead of constructing unconditional Rules definitions or tracking backing rule IDs. Enabling it requires human approval for every purchase on the card, followed by separate CVV confirmation for real-card purchases.
How to review
Stacked on #1239 because that introduces the paymentCards client. Requires Sapiom backend/UI PR #5917; the README and changelog document permissions, defaults, retry behavior and pending deployment/publication.
The branch-based CI trigger is inherited from #1239. Local verification of the combined #1239/#1251 stack passes: 137 core tests, 76 browser tests including real Chromium integration, core/browser type checks, CJS/ESM builds, core lint, CI security checks and PR-labeler checks. A real local API walkthrough verifies enable/pause/re-enable, persisted readback, stale-write rejection and setup-link readback. The walkthrough uses a seeded test card and performs no provider payment.
Risk & rollout
Complete the backend API and worker rollout before publishing and adopting these helpers or minting approval-enabled setup links. Purchase-policy writes require org.write; creating a setup link additionally needs org.transactions.write. Omitted approval options preserve the existing default-off setup without granting policy-editing authority.
Fix-forward: stop the affected card-management integration, correct the client request/response handling, and repeat persisted setting readback and stale-write rejection before resuming changes.