fix(airwallex): carry connector_order_id and access token in dedicated proto fields - #2028
fix(airwallex): carry connector_order_id and access token in dedicated proto fields#2028shuklatushar226 wants to merge 2 commits into
Conversation
…d proto fields
The Airwallex MIT leg confirms a pre-created PaymentIntent, so it needs the
connector_order_id from CreateOrder. RecurringPaymentServiceChargeRequest had
no field for it, so callers smuggled it through connector_feature_data as
{"connector_order_id": "..."} and the connector read that magic key back out.
Same story for the connector-customer call: CustomerServiceCreateRequest had no
`state` field, so the Bearer token travelled as {"access_token": "..."} in the
same blob.
That overloaded connector_feature_data — everywhere else an opaque,
connector-owned pass-through — with a second undocumented contract, and put
knowledge of one connector's wire format into the connector-agnostic layer.
Add the two missing fields instead:
- RecurringPaymentServiceChargeRequest.connector_order_id = 39
- CustomerServiceCreateRequest.state = 10
map both into PaymentFlowData, thread `state` through the composite authorize
path (which previously had no way to pass a token to customer-create at all),
and drop both fallback reads from the Airwallex connector.
Both fields are new optional tags, so the change is wire-compatible in each
direction.
Auto-applied by CI: - cargo +nightly fmt --all - make -C sdk generate (if applicable) - make docs (if applicable) This commit was automatically generated by GitHub Actions.
|
[blocking] Regenerate and commit the gRPC Rust artifacts for these proto changes. |
|
[blocking] Please regenerate and commit the Rust gRPC artifacts for the new |
2 participants
Why
Raised in review on hyperswitch#13278 — connector-specific logic had leaked into the connector-agnostic UCS transformer on the Hyperswitch side.
Two proto gaps were being worked around by overloading
connector_feature_data:RecurringPaymentServiceChargeRequestconnector_order_id{"connector_order_id": "..."}, connector read the key backCustomerServiceCreateRequeststate{"access_token": "..."}, connector read the key backAirwallex needs both: its MIT leg confirms a pre-created PaymentIntent (so it needs the id from
CreateOrder), and its customer API authenticates with a Bearer token separate from the merchant credentials.Everywhere else
connector_feature_datais an opaque, connector-owned blob round-tripped between legs. Overloading it with router-synthesized magic keys gave one field two contracts, with nothing but a string literal holding the two sides together — rename it on either side and it fails at runtime, not at build time.What
payment.proto: addRecurringPaymentServiceChargeRequest.connector_order_id = 39andCustomerServiceCreateRequest.state = 10types.rs: map both intoPaymentFlowData(thestate→access_tokenextraction is the same one the recurring-charge impl already uses)composite-service: threadstateinto the customer-create request, mirroring the neighbouringCustomerServiceGetRequestimplairwallex.rs: drop both fallback reads;get_access_token()now goes through the normal path like the other nine call sites in the fileNet +32/−31 — this removes more than it adds.
Notes
optionaltags (39and10are free at2026.07.07.2,2026.07.28.0, andmain), so the change is wire-compatible in both directions — old servers ignore them, new servers seeNone.connector_feature_dataworkaround never covered it. Threadingstatecloses that gap.cargo clippy --workspace --all-targetsclean.2026.07.07.2, which lacks both fields.