Rate limits should follow partner surfaces

What the public implementation shows

The gateway defines separate fixed-window policies and permit limits for authority, SIPS Connect, and dashboard endpoint groups.

Endpoint modules attach caller-specific policies rather than sharing one undifferentiated gateway bucket. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleOne global request limit cannot represent the operating importance of different payment interfaces.

The decision behind the mechanism

Segmentation prevents a reporting workload or one authority client from exhausting the capacity reserved for payment confirmation.

A global limit can let low-priority traffic crowd out the national payment integration path. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Assign policy by authenticated surface.
• Avoid queuing financial requests unless semantics support it.
• Return clear retry information.
• Measure limit use and rejection by policy.

How the control should be operated

Permit limits should be reviewed with traffic evidence, rejection metrics, queue policy, client identity, and incident overrides.

Capacity protection reflects business criticality while keeping throttling observable to partners. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.