feat(accounts): add the ISV payout schedule fields and funds_transfer_type on payouts - #653
Open
armando-rodriguez-cko wants to merge 2 commits into
Conversation
…_type on payouts From the 2026-08-05 spec. Verified against it with the RAG rather than the ticket text, which turned out to overstate the work. The ISV part is not five new schemas. The payout schedule endpoint gained an anyOf with a SaaS seller variant, and what that variant actually adds on the wire is two fields: balance_minimum, the amount to retain in the sub-entity's available balance, and carry_forward_enabled, whether a balance below the minimum rolls into the next payout. Both go on the request and the response. The ScheduleFrequency*Isv schemas serialise identically to the ones already here: same by_day array, same by_month_day array. Only the accepted values differ, and the API enforces them. Adding parallel classes with identical wire shapes would have doubled the public surface for nothing, so the constraints are documented on the existing classes instead: working days only for ISV weekly and daily, and only [1], [15], [1,15] or [1,16] for ISV monthly. The card payout side is one field, and the ticket points at the wrong half: funds_transfer_type already existed on the payout REQUEST via PaymentInstruction. What was missing is the response, where PaymentInstructionResponse carried only value_date. Two of the four tests cover absence rather than presence. A standard schedule must not emit balance_minimum or carry_forward_enabled at all, since either leaking in as a null or a zero would make the API read it as an ISV schedule, and both must come back null rather than 0/false so a caller can tell "not applicable" from "set to zero". Blocks C and D of the ticket need no work in Java: the hosted payment and payment link responses extend Resource, which already maps _links, and PaymentInstrumentRequest already has label, currency and instrumentDetails. Refs INT-1684.
The field that says where a sub-entity's payout actually goes was missing from both the request and the response, in all seven SDKs, and it never appeared in the swagger changelog, so it predates the point where changes started being tracked. Found while implementing the ISV fields in the same two classes. Riding along in INT-1684 rather than getting its own row: it is one property, and tracking a ticket per property costs more than it returns. Called out here and in the PR so it is not invisible. The doc comment carries the bit that is easy to get wrong: for SaaS sellers it is optional, but when supplied it must reference a verified payment instrument or the API rejects the request. The existing four tests were extended rather than new ones added, including the two that assert absence, since a payout destination leaking into a standard schedule request is the same class of bug as the ISV fields leaking in. Refs INT-1684.
🟢 Risk Classification: LOWApproval route: AI Auto-Approval Classification reasons
Operational gates
Files analysed: 8 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
|
![agent-wall-e[bot]](https://avatars.githubusercontent.com/in/3524837?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ Auto-approved — this PR meets all Low-risk criteria.
All checks passed, no unresolved comments, and the change classification is:
no_low_class_matchedprod_source_modified2.2.6_logical_extension:The change is purely additive, adding new optional fields to existing request/response POJOs on already-existing endpoints without introducing new endpoints, services, persisted data, auth changes, or external integrations.
wall-e 2026.06.19-02 · policy 376219bc71e6…
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two additions from the 2026-08-05 spec, verified against the spec and against the code before writing anything.
A. SaaS seller (ISV) payout schedules
GET/PUT /accounts/entities/{id}/payout-schedulesgained ananyOfwith a SaaS seller variant. On the wire that is two fields,balance_minimumandcarry_forward_enabled, on both the request and the response. They were missing in all seven SDKs.payment_instrument_idis also added: it was absent from both sides of this schedule, though it is not new in the spec.B.
instruction.funds_transfer_typeon the card payout responseThe field already existed on the payout request. This is the response side, where the instruction carried only
value_date.Tests
The ones that matter here are the negative cases, because getting them wrong is silent:
nullor0, the API would read a standard schedule as an ISV one.nullrather than0/false, so a caller can tell "not applicable" from "set to zero".Not breaking
Purely additive.
Refs INT-1684.