Under the Hood: Fixing the Payment Requests Endpoint in v0.1.51
Under the Hood: Fixing the Payment Requests Endpoint in v0.1.51
Version: 0.1.51
Affected area: Payment Requests —src/lib/letmc/payment-request.ts
Background
As part of the myProp rebuild from a Vue/Vuex + Amplify Lambda BFF architecture to a modern tRPC-based stack, a routing discrepancy was discovered in the payment requests flow. This post explains what was found, why it matters, and what needs to happen next.
The Problem
Original Architecture
In the original app, the Vuex store dispatched a POST request to:
POST /accounts/payment-requests
This hit an Amplify API Gateway → Lambda BFF, which handled authentication, constructed the AgentOS call, and returned a standardised envelope:
{
"success": "Request Succeeded!",
"data": { ... },
"status": "200",
"url": "/accounts"
}
The Lambda BFF internally called the correct AgentOS endpoint:
/{clientName}/payments/requests/{personID}?api_key={API_KEY}
Rebuilt Architecture
The rebuilt app replaces the Amplify Lambda BFF with tRPC via paymentRequestRouter. However, two issues were introduced:
-
Wrong AgentOS path: The tRPC handler was calling:
/v3/{shortName}/lettings/tenants/{id}/paymentrequestsinstead of the correct:
/{clientName}/payments/requests/{personID}?api_key={API_KEY} -
BFF envelope not replicated: The original
{ success, data, status, url }response shape was dropped, which breaks any consumer expecting that contract.
Why This Matters
- Incorrect AgentOS path means payment requests are sent to a non-existent or wrong endpoint, causing silent failures or unexpected errors for tenants attempting to make payment requests through the portal.
- Missing envelope shape breaks any existing frontend code or third-party integration that parses the
success,status, orurlfields from the response.
The Fix
1. Correct the AgentOS Endpoint
In src/lib/letmc/payment-request.ts, update the AgentOS API call to use the correct path:
// ❌ Before (incorrect)
const url = `/v3/${shortName}/lettings/tenants/${id}/paymentrequests`;
// ✅ After (correct)
const url = `/${clientName}/payments/requests/${personID}?api_key=${API_KEY}`;
2. Consumer Migration (BFF Envelope)
Since tRPC replaces the Amplify API Gateway, the BFF envelope shape ({ success, data, status, url }) is not required in the new architecture — as long as all consumers are updated to use the tRPC client interface instead of parsing raw HTTP responses.
Teams with integrations against the original /accounts/payment-requests POST endpoint should:
- Identify all call sites referencing the old endpoint or parsing the old envelope shape.
- Migrate those calls to use the tRPC
paymentRequestRouterclient. - Update response handling to use the tRPC response structure directly.
Checklist
- Update
src/lib/letmc/payment-request.ts— correct AgentOS path to/{clientName}/payments/requests/{personID}?api_key={API_KEY} - Audit all frontend consumers of
/accounts/payment-requests(POST) - Migrate consumers to the tRPC
paymentRequestRouterinterface - Remove any response parsing logic that expects the legacy BFF envelope shape
- Test end-to-end: tenant submits a payment request → correct AgentOS endpoint is called → success response returned
Architecture Reference
| Layer | Original | Rebuilt |
|---|---|---|
| Frontend call | Vuex action → POST /accounts/payment-requests | tRPC client → paymentRequestRouter |
| Middleware | Amplify Lambda BFF | tRPC server handler |
| AgentOS path | /{clientName}/payments/requests/{personID}?api_key= | ⚠️ Was incorrect — now corrected |
| Response shape | { success, data, status, url } | tRPC response object |