New Payment Write-back Requirements & Feasibility
Why This Matters
Every new payment write-back starts with a feasibility exercise. Understanding the steps — from feasibility doc to API prerequisites to field mapping — will prepare you to execute payment write-back tickets independently.
What You'll Learn
- Step 1: feasibility document — map Weave payment fields to PMS fields, note constraints, API prerequisites
- How to document API prerequisites: some PMSs require specific setup before a payment API can be called
- Field mapping exercise: Athena example — Weave payment fields mapped to Athena API fields with notes
- Constraints and limitations: some PMS payment APIs have restrictions the feasibility doc must capture
- How feasibility feeds into engineering implementation: the doc becomes the spec
- What happens after feasibility: implementation, testing, rollout
Watch Video
Lesson Summary
Implementing payment write-back for a new PMS starts with feasibility. The feasibility document maps each Weave payment field to the corresponding PMS field, documents API prerequisites (e.g., Athena requires a specific setup step before payments can be created), notes field constraints (optional vs required, data type restrictions), and lists any PMS limitations. This document becomes the engineering spec. After feasibility sign-off, implementation proceeds: add capability to standard.json, implement the payment write-back RPC, test with a real dev office, then roll out. The Athena integration is used as a concrete example throughout.