Card programmes

The two providers use different status vocabularies for the same concepts. The model normalises both.

Display mapping (STATUS_MAP / normalizeCardStatus):

Anything unmapped passes through unchanged.

Semantic predicates, which branch on the provider:

Marqeta identifies a card by token; Airwallex by card_id. normalizeCardId(raw) prefers token, falls back to card_id, then ''. mapMarqetaCard / mapAirwallexCard / mapSupplierCard handle the rest, including deriving lastFour from card_number or pan when the backend does not send it.

normalizeAirwallexStatus handles three backend shapes, and this is where "is this supplier registered?" is actually decided:

So airwallexStatus === null in the store means not registered, not not loaded — loadingAirwallexStatus is the loading flag.

connected_account_status, rfi and cards are named explicitly rather than left to the spread because the backend puts them either on db_record or beside it, depending on the shape. A record written before the backend added rfi normalises to null, which is how the panel knows to omit the row entirely.

Airwallex can raise an RFI against a connected account, and the endpoint reports it as { rfi_status, rfi_id, rfi_type }. The panel shows it as a row under the cardholder terms: a badge with the status, plus the type and the RFI id when one is outstanding. NO_RFI still renders, so an operator can tell "nothing outstanding" apart from "this record is too old to say".

The status vocabulary belongs to the backend — NO_RFI and ANSWERED are the confirmed values — so AirwallexRfiStatus stays an open union and both display helpers degrade rather than break:

An outstanding RFI does not change the onboarding state — deriveAirwallexState still keys off the connected account, cardholder and cards alone.

Issuing from the Airwallex panel on the supplier payment list branches on the selected form factor. VIRTUAL dispatches straight away; PHYSICAL first opens ChooseCardTypeComponent in shipping-only mode (data.shippingOnly === true), which skips provider and card-type selection and opens directly on the address form and the Expedite Shipping checkbox. Cancelling the dialog issues nothing.

The address is pre-filled from the supplier’s main owner, the same source Marqeta has always used, and the operator can edit it before ordering.

CardManagementService.issueAirwallexCard owns the payload rules:

Backend behaviour worth knowing:

Delivery data rides on the card record itself — every card in the cards array of GET suppliers/:key/airwallex carries shipping_applicable, delivery_address, delivery_status, tracking_code and tracking_link. There is no separate shipping read, so the expanded card row needs no extra request.

mapAirwallexOnboardingCard and mapAirwallexCard both fold these onto AirwallexCard, flattening delivery_address into a single display string. Note that the returned address uses Airwallex’s own shape (line1 / postcode), which is not the shape sent on create (address1 / zip).

AirwallexCardListComponent renders delivery status, the delivery address, the tracking code and a tracking link in the expanded row of a physical card. Values the backend has not filled in yet render as an em dash. Virtual rows show none of this and have no refresh action.

The stored values only move when something asks Airwallex, so Refresh status calls the refresh endpoint and then emits changed, which re-runs FetchAirwallexStatus and brings back both the refreshed card status and its delivery fields.

Every Airwallex operation fails closed and the backend message names the cause, so no AWX call is allowed to fail silently. extractAirwallexError(error, fallback) in supplier.reducers.ts is the one place that digs the message out, preferring error.error.msg, then error.error.message, then a plain-string body, then error.message, and only then the caller’s fallback.

Before it creates a Connected Account the backend checks the supplier’s compliance documents and refuses the submit if any required one is missing. Some of those refusals can be forced: the same PUT is repeated with overwrite_missing_documents: true, and the backend skips the missing files and submits what it has.

Whether a refusal can be forced is the backend’s decision, and it states it outright. The 400 body carries the verdict alongside the prose:

Both extra fields are optional. can_overwrite is the gate — the resubmit is offered if and only if it is the literal boolean true. Absent, false, or a truthy-but-not-true value such as 'true' or 1 all mean no resubmit, because an unrecognised shape must fail closed rather than send the operator on a round trip the backend has already ruled out. missing_documents names what the supplier still owes; airwallexDocumentLabel in card.model.ts maps the known codes to readable labels and tidies up an unknown one rather than dropping it, since the operator has to chase the file either way.

resolveCardholderBlock turns that into an AirwallexSubmitBlock of the verbatim message, an overridable boolean and a missingDocuments list. SupplierPaymentListComponent then opens ConfirmDialogComponent for every refusal, with the message in its alertMessage box and the documents in its details list:

Either way no toast is raised: it would stack on top of the modal, and the inline awx-cardholder-error alert already keeps the reason on screen after the dialog closes.

Two guards matter:

There is no NgRx slice. The page holds its state in the components, as the rest of the Airwallex card transactions tab does.

AwxDisputesPageComponent resolves the supplier key from selectSupplierDetails and passes it down as an @Input, so it arrives after first render. AwxDisputeListComponent therefore loads on ngOnChanges as well as ngOnInit, and never fetches on a falsy key — a fetch in ngOnInit alone would put undefined in the URL.

AwxDisputeStatus is a string-literal union over exactly those eight values. Airwallex enforces the rules server-side and rejects a disallowed action with a 400; the UI derives the affordances from status so an operator is never offered a button that cannot succeed.

The list renders detailed_status beside the status pill when it differs from status, so the Airwallex sub-state is visible without a column of its own. Submit and Cancel each run confirm → call → toast → reload, with a per-row busyDisputeId disabling that row while a call is in flight. Filtering by status is client-side: the list is small enough to fetch whole, and there is no pagination.

AwxDisputesService on internalApiUrl, which already ends in internal/:

Every one of them returns a dispute object. The fields are a snake_case pass-through of the Airwallex shape — the backend does not reshape it, so the model does not camel-case it either, matching AwxTransaction on the same tab. Treat the field set as open.

validateEvidenceFile mirrors the limits the backend enforces so the operator hears about a bad file before committing to a 20 MB upload. It returns an operator-facing message, or null when the file is acceptable. The backend remains the source of truth.

The dialog validates on selection, not on upload, and a failure disables the upload button — the request is never sent. It binds app-input-file, which writes a FileInputModel rather than a raw File, so the dialog reads control.value?.files?.[0].

A dispute is keyed on the transaction event, not the transaction, so AwxTransaction and AwxTransactionMapper.map carry transaction_event_id, sitting beside transaction_id where it belongs rather than at the end of the constructor’s twenty positional parameters. That is safe only because AwxTransactionMapper.map is the single construction site in src/; add another and the argument order becomes a trap.

The grid’s Dispute column sits after the Transaction ID column — anywhere after the pinned ROW_COUNT_COLUMN_DEF, which has to stay leftmost. It renders a link through cellRenderer and handles the click in onCellClicked, destructuring ({ data }) because an action column needs the row rather than the cell value. It navigates to the disputes page with createFor (the event id), transactionId and amount on the query string; the list component opens the create dialog from those parameters and then clears them with replaceUrl, so reloading or navigating back does not reopen it.

The create dialog prefills and disables the event-id control — the operator can confirm which event they are disputing but cannot retype it — and reads the value from the injected dialog data, since Angular omits disabled controls from form.value. Optional fields are omitted from the payload when empty rather than sent blank: an absent amount disputes the full transaction, which is not the same request as 0. reference is capped at 20 characters (AWX_DISPUTE_REFERENCE_MAX_LENGTH) with a counter and a field-level error. On a backend rejection the dialog stays open with the typed input intact.

Discoverability is inherited too, and it is thinner than it looks: the supplier tab bar has no Airwallex entry at all — supplier-box-header-old only adds card-transactions/marqeta as "Seller Card". Operators reach the Airwallex tab through the EVA supplier menu, which app.component.ts enables via isSellerCardAwx when the supplier has a PCARD-AWX payment type, or by typing the URL. The disputes page is exactly as discoverable as the tab it hangs off, no more. This predates GAR-2368. See iframe messaging for the menu-conditions message.