> ## Documentation Index > Fetch the complete documentation index at: https://developer.finogates.com/llms.txt > Use this file to discover all available pages before exploring further. # Charge a Saved Card into a Card-Acquiring Merchant > Charge a saved card and park the payment for review. The card is identified by ``payment_method_id`` and the receiving card-acquiring account by ``card_acquiring_id``. The payment lands at ``pending_review`` for a Finogate admin to approve or reject. By default the funds land in the card-acquiring account owner's primary wallet for the currency. Send ``destination_wallet_id`` to credit one specific wallet instead — any wallet under your tenant, primary or not, whose currency matches ``currency`` (which defaults to ``USD``). The resolved wallet comes back as ``destination_wallet_id`` on the response. A ``409`` means the wallet cannot take the credit (closed, suspended or frozen), or that the card-acquiring account settles to an external bank account and so has no wallet leg to redirect; a ``422`` means the wallet belongs to another tenant or holds a different currency. Send ``splits`` to credit **several** wallets from this one charge — for example the end user's share and your own fee. Each leg names a wallet (same rules as ``destination_wallet_id``) and an amount, and the amounts must add up exactly to ``amount``. Every leg shows in its wallet's pending balance while the payment awaits review, and all legs become spendable together on approval; a rejection, void or refund claws every leg back or none. Mutually exclusive with ``destination_wallet_id``. The resolved legs come back as ``splits`` on the response and ride on this payment's webhooks. How the card is billed depends on its configured charge mode, returned as ``charge_mode`` on the response. ``auth_capture`` authorizes (holds) the card now and screens AVS/CVV, then captures on approval — a rejection voids the hold. ``sale`` places no hold: nothing reaches the card until an admin approves, and then it is charged once. A card whose manual review is still open (``verification_status`` of ``awaiting_documents`` or ``pending``) **can** be charged here, unlike on any other saved-card surface: this payment parks for an operator anyway, so that approval covers the open card review too. The payment comes back with ``needs_review: true``. Its AVS/CVV rules stay strict, and a card an admin has **rejected** is still refused with a ``409``. A ``201`` always means a live payment was recorded. The two outcomes that collect nothing are errors, keyed by ``detail.code``: * ``422 card_declined`` — the issuer declined, or the card failed the AVS/CVV policy (any held authorization is voided). * ``400 card_processor_error`` — the charge could not be attempted at all: the processor was unreachable, misconfigured, or answered something unusable. Nothing was established about the card, so this is a retry rather than a reason to ask the cardholder for another one. Both carry the same body: the payment record exists at ``failed``, its id is on the error as ``payment_intent_id``, the collapsed cause as ``failure_reason``, and ``message`` is the processor's own wording for what happened. The key **is** consumed, so a replay returns this same error. Supply a unique ``idempotency_key`` — a replay returns the same record. ## OpenAPI ````yaml POST /v1/platform/payments/card-to-merchant openapi: 3.1.0 info: title: Finogate Platform API v1 version: 0.1.0 servers: - url: https://api-sandbox.finogates.com description: Sandbox - url: https://api.finogates.com description: Production security: [] tags: - name: auth - name: users - name: payees - name: verification - name: bank accounts - name: card processing - name: digital-assets - name: international - name: fees - name: onboarding - name: pending-applications - name: wallets - name: payments - name: document mailing - name: merchant onboarding - name: catalog - name: webhooks - name: screening - name: Platform - File Scanning - name: phone-numbers - name: sms - name: calls - name: listings - name: Card Transfers - name: embed-tokens paths: /v1/platform/payments/card-to-merchant: post: tags: - payments summary: Charge a saved card into a card-acquiring merchant description: >- Charge a saved card and park the payment for review. The card is identified by ``payment_method_id`` and the receiving card-acquiring account by ``card_acquiring_id``. The payment lands at ``pending_review`` for a Finogate admin to approve or reject. By default the funds land in the card-acquiring account owner's primary wallet for the currency. Send ``destination_wallet_id`` to credit one specific wallet instead — any wallet under your tenant, primary or not, whose currency matches ``currency`` (which defaults to ``USD``). The resolved wallet comes back as ``destination_wallet_id`` on the response. A ``409`` means the wallet cannot take the credit (closed, suspended or frozen), or that the card-acquiring account settles to an external bank account and so has no wallet leg to redirect; a ``422`` means the wallet belongs to another tenant or holds a different currency. How the card is billed depends on its configured charge mode, returned as ``charge_mode`` on the response. ``auth_capture`` authorizes (holds) the card now and screens AVS/CVV, then captures on approval — a rejection voids the hold. ``sale`` places no hold: nothing reaches the card until an admin approves, and then it is charged once. A card whose manual review is still open (``verification_status`` of ``awaiting_documents`` or ``pending``) **can** be charged here, unlike on any other saved-card surface: this payment parks for an operator anyway, so that approval covers the open card review too. The payment comes back with ``needs_review: true``. Its AVS/CVV rules stay strict, and a card an admin has **rejected** is still refused with a ``409``. A ``201`` always means a live payment was recorded. The two outcomes that collect nothing are ``422``s, keyed by ``detail.code``: * ``card_declined`` — the issuer declined, or the card failed the AVS/CVV policy (any held authorization is voided). The payment record exists at ``failed``; its id is on the error as ``payment_intent_id`` and the specific cause as ``failure_reason``. The key **is** consumed, so a replay returns this same error. Supply a unique ``idempotency_key`` — a replay returns the same record. operationId: >- create_card_to_merchant_payment_v1_platform_payments_card_to_merchant_post requestBody: content: application/json: schema: $ref: '#/components/schemas/PlatformCardToMerchantCreate' required: true responses: '201': description: Successful Response content: application/json: schema: $ref: '#/components/schemas/CommonResponse' '422': description: The charge collected nothing — the card was declined. content: application/json: examples: card_declined: summary: Issuer declined / AVS-CVV policy fail value: detail: code: card_declined message: The card was declined. payment_intent_id: 7f3c1b2a-9d84-4e15-8c26-0b7a5d3e1f90 failure_reason: card_security_check_failed last4: '2420' brand: Visa security: - _AuthenticatedBearer: [] components: schemas: PlatformCardToMerchantCreate: properties: payment_method_id: type: string format: uuid title: Payment Method Id description: Public id of the saved card to charge. card_acquiring_id: anyOf: - type: string format: uuid - type: 'null' title: Card Acquiring Id description: >- Public id of the card-acquiring merchant to deposit into. Optional — when omitted the tenant's first approved (oldest created) card-acquiring account is used. When supplied it is always honoured; there is no fallback, and a card vaulted under a different account is refused. payer_user_id: type: string format: uuid title: Payer User Id description: Public id of the payer (cardholder) user being charged. destination_wallet_id: anyOf: - type: string format: uuid - type: 'null' title: Destination Wallet Id description: >- Public id of the exact wallet to credit. Optional — when omitted the funds land in the card-acquiring account owner's primary wallet for the currency. The wallet must belong to this tenant and its currency must match ``currency``; it does not have to be a primary wallet. Not accepted when the card-acquiring account settles to an external bank account. amount: anyOf: - type: number exclusiveMinimum: 0 - type: string pattern: ^(?!^[-+.]*$)[+-]?0*\d*\.?\d*$ title: Amount description: Amount to hold, major units. currency: type: string maxLength: 3 minLength: 3 title: Currency default: USD idempotency_key: type: string maxLength: 120 minLength: 1 title: Idempotency Key description: Caller-chosen unique key; a replay returns the same record. metadata: anyOf: - additionalProperties: true type: object - type: 'null' title: Metadata description: Optional caller metadata stored on the record. type: object required: - payment_method_id - payer_user_id - amount - idempotency_key title: PlatformCardToMerchantCreate description: |- Request body for ``POST /v1/platform/payments/card-to-merchant``. The card is identified by ``payment_method_id`` (a card already vaulted for a user under the tenant). ``card_acquiring_id`` selects the NMI merchant (MID) the funds deposit into; it must match the merchant the card was vaulted under (vault tokens are MID-namespaced). Omit it to use the tenant's first approved card-acquiring account. CommonResponse: properties: status_code: type: integer title: Status Code description: HTTP status code for the response. data: title: Data description: Payload or error details. query_generated_time: type: integer title: Query Generated Time description: >- UTC timestamp (milliseconds since epoch) when response was generated. type: object required: - status_code - data - query_generated_time title: CommonResponse description: |- Standard response wrapper for single-object responses and errors. Generic over the payload type. A route that declares ``CommonResponse[SomeModel]`` gets the real ``data`` schema rendered in OpenAPI/Swagger; a bare ``CommonResponse`` leaves ``data`` untyped. securitySchemes: _AuthenticatedBearer: type: oauth2 flows: password: scopes: {} tokenUrl: /v1/platform/auth/token ````