> ## 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. # Update a Pending Card Processing Application > Correct a card-processing application that is still under review. Use this while an application is pending — for example when an underwriter asks for a clearer bank statement or a corrected volume figure. Once the application has been **approved, declined or suspended** it can no longer be edited and this returns `409`: at that point the packet is the record the decision was made on. Addressed by `card_acquiring_id`, the id returned when the merchant was onboarded. An id belonging to another platform returns `404`. **Everything is optional. Only what you send changes.** An omitted block is left alone entirely, and an omitted field inside a block you do send is left alone too — so you can correct one figure without restating the packet. The same applies to documents: a file part replaces that slot, and a slot with no part keeps whatever is stored. The **`payload`** form field is a JSON object, all keys optional: - `merchant_info` — any of `average_ticket_minor`, `monthly_volume_minor`, `max_ticket_minor`. The max-versus-average rule is checked against the merged result, so raising only the average is validated against the stored maximum. - `business_data` — any of `business_type`, `formation_date`, `mcc`, `business_phone`, `phone_country_code`, `dba`, `website`, `registration_number`, `business_description`, `contact_first_name`, `contact_last_name`, `contact_email`, `business_address`, `ownership`, `business_documents`. Sending `business_documents` **replaces the whole list**, so include every document you want to keep (2 to 5 entries). - `kyc` — any identity field: `first_name`, `last_name`, `email`, `dob`, `phone_country_code`, `phone_no`, `ssn`, `address`, `city`, `state`, `zip`, `country`, `id_type`, `id_no`, and the image links `selfie`, `id_front_img`, `id_back_img`. **Three fields cannot be changed** and are rejected with `422` if sent: `business_legal_name`, `business_ein` and `business_email`. The first two are the pair used to decide whether a resubmission is the same business, and the third is the key the merchant record is found by — editing any of them would silently point the application at a different company. Onboard a new merchant instead. File rules match the create endpoint: `https://` links only, publicly reachable, PNG/JPG/JPEG/PDF only, 10 MB per uploaded document and 7 MB per linked file. Links are downloaded and re-hosted, and no two files in one request may be byte-identical. **Editing a verification sends its check back for review.** A change to `kyc` returns the identity (KYC) check to `in_review`, and a change to `kyb` returns the business (KYB) check to `in_review` — the same state a fresh submission lands in, so an edited check queues alongside new ones. A verification verdict describes the evidence it was given — the identity details, or the legal name, EIN and documents — and this call changes that evidence, so an approval that stood against the old details would not describe what is now on file. Only the axis you edit moves: send just `kyb` and the identity check is left alone. Supplying a new `inquiry_id` also re-decides the identity check, since the re-sync takes its status from the verification provider. Edit a verification only when you mean to have it re-reviewed. The card-processing application itself is never approved or declined by this endpoint. ## OpenAPI ````yaml PUT /v1/platform/merchant-onboarding 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/merchant-onboarding: put: tags: - merchant onboarding summary: Update a Pending Card Processing Application description: >- Correct a card-processing application that is still under review. Use this while an application is pending — for example when an underwriter asks for a clearer bank statement or a corrected volume figure. Once the application has been **approved, declined or suspended** it can no longer be edited and this returns `409`: at that point the packet is the record the decision was made on. Addressed by `card_acquiring_id`, the id returned when the merchant was onboarded. An id belonging to another platform returns `404`. **Everything is optional. Only what you send changes.** An omitted block is left alone entirely, and an omitted field inside a block you do send is left alone too — so you can correct one figure without restating the packet. The same applies to documents: a file part replaces that slot, and a slot with no part keeps whatever is stored. The **`payload`** form field is a JSON object, all keys optional: - `merchant_info` — any of `average_ticket_minor`, `monthly_volume_minor`, `max_ticket_minor`. The max-versus-average rule is checked against the merged result, so raising only the average is validated against the stored maximum. - `business_data` — any of `business_type`, `formation_date`, `mcc`, `business_phone`, `phone_country_code`, `dba`, `website`, `registration_number`, `business_description`, `contact_first_name`, `contact_last_name`, `contact_email`, `business_address`, `ownership`, `business_documents`. Sending `business_documents` **replaces the whole list**, so include every document you want to keep (2 to 5 entries). - `kyc` — any identity field: `first_name`, `last_name`, `email`, `dob`, `phone_country_code`, `phone_no`, `ssn`, `address`, `city`, `state`, `zip`, `country`, `id_type`, `id_no`, and the image links `selfie`, `id_front_img`, `id_back_img`. **Three fields cannot be changed** and are rejected with `422` if sent: `business_legal_name`, `business_ein` and `business_email`. The first two are the pair used to decide whether a resubmission is the same business, and the third is the key the merchant record is found by — editing any of them would silently point the application at a different company. Onboard a new merchant instead. File rules match the create endpoint: `https://` links only, publicly reachable, PNG/JPG/JPEG/PDF only, 10 MB per uploaded document and 7 MB per linked file. Links are downloaded and re-hosted, and no two files in one request may be byte-identical. **Editing a verification sends its check back for review.** A change to `kyc` returns the identity (KYC) check to `in_review`, and a change to `kyb` returns the business (KYB) check to `in_review` — the same state a fresh submission lands in, so an edited check queues alongside new ones. A verification verdict describes the evidence it was given — the identity details, or the legal name, EIN and documents — and this call changes that evidence, so an approval that stood against the old details would not describe what is now on file. Only the axis you edit moves: send just `kyb` and the identity check is left alone. Supplying a new `inquiry_id` also re-decides the identity check, since the re-sync takes its status from the verification provider. Edit a verification only when you mean to have it re-reviewed. The card-processing application itself is never approved or declined by this endpoint. operationId: update_merchant_v1_platform_merchant_onboarding_put requestBody: content: multipart/form-data: schema: $ref: >- #/components/schemas/Body_update_merchant_v1_platform_merchant_onboarding_put required: true responses: '200': description: The application was updated. content: application/json: schema: $ref: '#/components/schemas/CommonResponse_MerchantOnboardingRead_' example: status_code: 200 data: user_id: 228e4b03-6831-4b63-ad8e-2250d01f6d64 kyb_id: 69b336da-331c-4ddf-8ac5-0a0557c7f279 card_acquiring_id: 07f78e86-b3c6-4761-84ae-22176ca015c1 query_generated_time: 1712847600000 '409': description: >- The application has already been decided and can no longer be edited. '422': description: Validation Error content: application/json: schema: $ref: '#/components/schemas/HTTPValidationError' security: - _AuthenticatedBearer: [] components: schemas: Body_update_merchant_v1_platform_merchant_onboarding_put: properties: payload: type: string title: Payload description: >- The application to edit and the fields to change, sent as JSON text. Only `card_acquiring_id` is required. voided_check: anyOf: - type: string format: binary - type: 'null' title: Voided Check description: Replacement voided check. Omit to keep the stored one. bank_statements: anyOf: - type: string format: binary - type: 'null' title: Bank Statements description: Replacement bank statements. Omit to keep the stored one. processing_statements: anyOf: - type: string format: binary - type: 'null' title: Processing Statements description: Replacement processing statements. Omit to keep the stored one. type: object required: - payload title: Body_update_merchant_v1_platform_merchant_onboarding_put CommonResponse_MerchantOnboardingRead_: properties: status_code: type: integer title: Status Code description: HTTP status code for the response. data: $ref: '#/components/schemas/MerchantOnboardingRead' 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[MerchantOnboardingRead] HTTPValidationError: properties: detail: items: $ref: '#/components/schemas/ValidationError' type: array title: Detail type: object title: HTTPValidationError MerchantOnboardingRead: properties: user_id: type: string format: uuid title: User Id description: The merchant's public id. kyb_id: type: string format: uuid title: Kyb Id description: Public id of the business (KYB) record. card_acquiring_id: type: string format: uuid title: Card Acquiring Id description: >- Public id of the card-acquiring application. Use it against `GET /v1/platform/card-processing/{application_id}`. type: object required: - user_id - kyb_id - card_acquiring_id title: MerchantOnboardingRead description: >- The three ids a call produced — handles, not records. Returned by both endpoints that end in a filed application: the one-shot ``POST /v1/platform/merchant-onboarding``, which creates all three records, and ``POST /v1/platform/card-processing``, which files an application against a user and business check that already exist and so reports back the ids it was given alongside the one it created. Same outcome, same shape — an integrator handling one does not need a second reader for the other. Nothing is approved by either. None of the records' detail is echoed back: it is data the caller already sent, and re-emitting it would spread personal and business information across another response body and another log line for no gain. Nothing is lost — each id is the key to the endpoint that owns that record, and that is where the current review status is read from: * ``card_acquiring_id`` -> ``GET /v1/platform/card-processing/{id}`` * ``kyb_id`` -> ``GET /v1/platform/card-processing/kybs/{kyb_id}`` * ``user_id`` -> ``GET /v1/platform/users/verification/{user_id}`` and ``GET /v1/platform/users/kyb-records/{user_id}`` ValidationError: properties: loc: items: anyOf: - type: string - type: integer type: array title: Location msg: type: string title: Message type: type: string title: Error Type type: object required: - loc - msg - type title: ValidationError securitySchemes: _AuthenticatedBearer: type: oauth2 flows: password: scopes: {} tokenUrl: /v1/platform/auth/token ````