Conversation
| }; | ||
|
|
||
| /** Action to update fiat payment state for a transaction. */ | ||
| export type TransactionPayControllerUpdateFiatPaymentAction = { |
| /** Fiat payment state stored per transaction. */ | ||
| export type TransactionFiatPayment = { | ||
| /** Entered fiat amount for the selected payment method. */ | ||
| amount: string | null; |
There was a problem hiding this comment.
Should we go with amountFiat to be explicit and avoid breaking changes?
Assuming we'll also want to record the original input value.
| /** Selected fiat payment method ID. */ | ||
| selectedPaymentMethodId: string | null; | ||
|
|
||
| /** Quick-buy order ID in normalized format (/providers/{provider}/orders/{id}). */ |
There was a problem hiding this comment.
As we don't persist, should we instead store transactionId in the Ramps state?
| amount: string | null; | ||
|
|
||
| /** Selected fiat payment method ID. */ | ||
| selectedPaymentMethodId: string | null; |
There was a problem hiding this comment.
Minor, if this is required, but can not exist initially, should we instead do an optional instead of null to match other types?
| }; | ||
|
|
||
| /** Request to update fiat payment state for a transaction. */ | ||
| export type UpdateFiatPaymentRequest = { |
There was a problem hiding this comment.
While they align, should we do a union of TransactionFiatPayment, can always diverge later if needed?
|
|
||
| ### Added | ||
|
|
||
| - Add `fiatPayment` transaction state into `transactionData` and `updateFiatPayment` atomic patch action, including defaults initialization and payment-token reset behavior ([#8093](https://github.com/MetaMask/core/pull/8093)) |
There was a problem hiding this comment.
Minor, is everything after the comma needed?
| selectedPaymentMethodId: null, | ||
| }; | ||
|
|
||
| const patch = pickBy( |
There was a problem hiding this comment.
Rather than doing a pickBy which has implicit overwrite behaviour, should we go the callback route like in updateTransactionConfig so it's explicit and totally flexible?
2 participants
Explanation
Adds
fiatPaymentstate toTransactionPayControllerand introduces an atomicupdateFiatPaymentAPI with incremental patch semantics.TransactionDatanow includesfiatPayment(selectedPaymentMethodId,amount,quickBuyOrderId), the newTransactionPayController:updateFiatPaymentaction is registered and exported, and transaction initialization/reset paths now consistently default fiat fields to null (including reset on payment-token changes).References
Checklist
Note
Medium Risk
Changes the shape and initialization/reset behavior of
TransactionPayControllerper-transaction state, which may affect downstream consumers and state-dependent logic. Adds a new messenger action and mutation path that needs validation across clients integrating pay flows.Overview
Adds a new
fiatPaymentobject to per-transactiontransactionData(trackingamount,selectedPaymentMethodId, andquickBuyOrderId) with defaultnullinitialization when a transaction entry is first created.Introduces an atomic
TransactionPayController:updateFiatPaymentmessenger action andupdateFiatPaymenthelper that applies patch semantics (only updates provided fields; supports clearing vianull) and throws if the transaction cannot be found. Updating the payment token now also resetsfiatPaymentto defaults to clear any prior payment-token-specific fiat state; types/exports and tests are updated accordingly, and the changelog is amended.Written by Cursor Bugbot for commit d8c2b71. This will update automatically on new commits. Configure here.