Update internal account
Update mutable fields on an internal account. Today this supports updating the wallet privacy setting for an Embedded Wallet internal account.
Updating wallet privacy is a two-step signed-retry flow:
-
Call
PATCH /internal-accounts/{id}with the request body{ "privateEnabled": true }and no signature headers. Grid returns202withpayloadToSign,requestId, andexpiresAt. -
Use the session API keypair of a verified authentication credential on the same internal account to build an API-key stamp over
payloadToSign, then retry with that full stamp as theGrid-Wallet-Signatureheader and therequestIdechoed back as theRequest-Idheader. The retry body must carry the same update fields submitted in step 1. The signed retry returns200with the updated internal account.
Authorizations
Headers
Body
Partial request body for PATCH /internal-accounts/{id}. At least one update field must be provided. On step 1 of the signed-retry flow Grid binds the submitted update fields into payloadToSign; on step 2 the client echoes the same fields back and Grid applies the update to the internal account.
Response
Signed retry accepted. Returns the updated internal account.
Classification of an internal account.
INTERNAL_FIAT: A Grid-managed fiat holding account (for example, the USD holding account used as the source for Payouts flows).INTERNAL_CRYPTO: A Grid-managed crypto holding account denominated in a stablecoin such as USDC.EMBEDDED_WALLET: A self-custodial Embedded Wallet provisioned for the customer. Outbound transfers require a session signature produced by the customer's device — see the Embedded Wallets guide.RULE_BASED: An additional account number for an existing account holder, with a routing rule attached, so incoming payments can be attributed to a specific payer and swept automatically. Created withPOST /internal-accounts.BULK_SETTLEMENT: An account for receiving bulk payments (for example, a single settlement from a payment processor) that the platform then pays out to its customers. Only a platform can hold one, and funds in it can move only to the platform's customers.
INTERNAL_FIAT, INTERNAL_CRYPTO, EMBEDDED_WALLET, RULE_BASED, BULK_SETTLEMENT Status of a Grid internal account. The status determines whether the account can send or receive payments.
PENDING: The account is under review and is being provisioned. The account cannot send or receive payments until provisioning completes.PENDING_AUTHORIZATION: The account is provisioned but waiting for the account holder to satisfy its Strong Customer Authentication challenge (scaChallenge). OnlyRULE_BASEDaccounts for customers in a region where SCA is required (the EU) enter this status. The account cannot receive payments until it is authorized withPOST /internal-accounts/{id}/authorize.ACTIVE: The account is ready to send and receive payments.CLOSED: The account cannot send or receive payments. A customer can initiate the closing of an internal account, after which the account transitions to this status.FROZEN: The account cannot send or receive payments. Grid may freeze an account in response to compliance or fraud signals; payments are blocked while the account remains frozen.FAILED: The account could not be provisioned. Grid was unable to create the underlying account, so it cannot send or receive payments and requires remediation.
PENDING, PENDING_AUTHORIZATION, ACTIVE, CLOSED, FROZEN, FAILED "ACTIVE"
The Strong Customer Authentication challenge the account holder must satisfy before a RULE_BASED account opens. Present only while the account is PENDING_AUTHORIZATION, and only for customers in a region where SCA is required (the EU). Authorize it with POST /internal-accounts/{id}/authorize. If the challenge expires, retry the create request with the same Idempotency-Key to receive a new one.
Funds a RULE_BASED account's sweep converted but could not deliver to the rule's destination, by currency. They are held for the account holder and can be moved to their own account in that currency with POST /internal-accounts/{id}/stranded-funds/transfer. Omitted when there are none, and for every account other than a RULE_BASED one.
Actions supported for a card issued now with this account as its funding source. They can change if the platform's card routing changes and do not describe cards already issued using the account. The funding source a create request supplies selects the issuer and therefore the resulting card's capabilities; read this field from that account. Absent when this account cannot fund a card.