feat(payment_terms): REST API write and read

[D1353L]

Context

Earlier steps in this stack added the structured payment_term to customers and billing entities, with the net_payment_term integer as a compatibility alias. This PR exposes it via the REST API. Before this change, clients could only send the integer.

Description

Write path

• payment_term is accepted on customer and billing entity create/update.
• PaymentTerms::ValidateService runs in all five write services before any persistence. Invalid input returns a validation error.
• The redundant direct net_payment_term column writes are removed. PaymentTerms::AssignService is now the only term write path.
• A new RawPaymentTermParams controller concern copies the raw payment_term and net_payment_term values into the permitted params. Without this concern, invalid input would be dropped silently instead of returning a validation error.
• PaymentTerms::ValidateService normalizes its input, so ActionController::Parameters and plain hashes give the same result.

Read path

• Added payment_term to customer and billing entity serializers.
• The invoice serializer returns the snapshotted payment_term. For invoices from before this feature, it builds {term_type: "net", days: N} from the invoice's own integer.

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — structured payment-term support is incomplete across sibling APIs and still has invalid-input failure paths.

• Expose payment_term on the customer and billing-entity GraphQL object/input types and cover those paths. A non-net term written through V1 currently cannot be read or edited through the sibling GraphQL API; it appears there only as net_payment_term: null.
• Make raw-param preservation handle array-shaped wrong types recursively and add request coverage. In CustomersController, payment_term: [{term_type: "net"}] copies unpermitted nested parameters into permitted, so the subsequent to_h raises instead of returning the intended payment_term: ["invalid_format"] response.
• Apply payment_term precedence consistently during validation. The services validate net_payment_term even when payment_term is present, so an invalid legacy alias rejects a request that AssignService documents as ignoring because the structured term wins.

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — Organizations::CreateService ignores the newly possible validation failure returned by BillingEntities::CreateService.

• Propagate that child failure and add a regression spec proving invalid payment-term input rolls back organization/API-key creation; currently the outer service reports success and commits an organization without its default billing entity.

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: PASS · CI green

PASS — Structured payment terms and the legacy alias are handled consistently across REST parameter parsing, service validation/assignment, and serializers. Coverage exercises valid, invalid, null, and precedence cases; focused specs could not be executed locally because the prescribed lago wrapper/API container is unavailable.

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — malformed net_payment_term values can still be silently discarded on the organization API sibling path.

• Preserve the raw value in Api::V1::OrganizationsController#input_params and add request coverage: this endpoint also accepts net_payment_term and delegates to BillingEntities::UpdateService, but strong params remove hash/array values before the new validator sees them, so the request can succeed without applying or rejecting the field.