# RevCent MCP Operation: `EditPaymentProfile` This document explains the `EditPaymentProfile` MCP operation and how an MCP should safely edit an existing Payment Profile. A Payment Profile controls the payment-routing flow that ultimately processes credit card payments. Editing an existing Payment Profile is more dangerous than creating a new disabled profile because the profile may already be used by active products, subscriptions, trials, pending-sale recovery, or production checkout flows. Sources: - RevCent Payment Profile Overview — `https://revcent.com/documentation/markdown/mcp/operation/OverviewPaymentProfile.md` - RevCent API/MCP schema for `EditPaymentProfile` - RevCent API/MCP schema for `GetPaymentProfile` - RevCent Knowledge Base: Payment Profile — `https://kb.revcent.com/en/payments/credit-card/next-gen-payment-profile` --- --- # Read the Payment Profile Overview First Before creating, editing, reviewing, or deeply configuring Payment Profiles, AI/MCP should read the Payment Profile overview: ```text https://revcent.com/documentation/markdown/mcp/operation/OverviewPaymentProfile.md ``` The overview explains Payment Profiles as a whole, including: ```text What Payment Profiles are. Why Payment Profiles are critical credit-card payment infrastructure. How payment routing works in RevCent. How gateway groups, gateways, failsafe gateways, retries, filters, Functions, metadata, abort paths, and process-payment nodes fit together. How Payment Profiles affect initial sales, pending sale recovery, subscription renewals, and trial expirations. Why incorrect Payment Profile logic can break checkout, route payments incorrectly, or prevent credit-card payments from being processed. ``` This operation file is focused on the specific API/MCP operation. The overview provides the broader conceptual context AI/MCP should understand before making Payment Profile design or edit decisions. ## Operation Summary `EditPaymentProfile` edits a previously created Payment Profile using its 20-character Payment Profile ID. Important schema behavior: - `payment_profile_id` is required. - Only include properties you want to modify. - Omitted properties remain unchanged. - If editing `payment_flow`, treat it as a full payment-routing logic graph. - A payment flow should still have, at minimum: - `start_payment_request` - `action_choose_gateway` - `action_process_payment` - Only one `start_payment_request` node can be present. --- ## Required Input | Field | Type | Required | Description | |---|---:|---:|---| | `payment_profile_id` | string | Yes | 20-character Payment Profile ID to edit. | Optional fields: | Field | Type | Description | |---|---:|---| | `name` | string | Update the Payment Profile name. Must remain unique. | | `description` | string | Update the Payment Profile description. | | `enabled` | boolean | Enable or disable the Payment Profile. | | `payment_flow` | array | Replace/update the Payment Profile flow. This is the most consequential edit. | Minimal request shape: ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX" } ``` --- # Critical Warning: Consequences of Editing an Existing Payment Profile A Payment Profile is live payment infrastructure. Editing an existing Payment Profile can immediately affect real credit card processing if that profile is enabled or actively used. Potential consequences include: - Valid payments may stop processing. - Payments may route to the wrong gateway. - A business/corp may accidentally process through another business/corp’s gateways. - Subscriptions may fail to renew. - Trial expirations may fail to bill. - Pending sale recovery may stop working. - Retry paths may run too often. - Hard declines may retry when they should stop. - Soft declines may abort when they should retry. - Gateway response filters may match the wrong responses. - Kill terms may cancel/void sales unexpectedly. - Missing failsafe gateways may cause gateway selection errors. - Custom Functions may timeout and block payment flow. - Metadata nodes may be inserted without continuing the main payment path. - A broken flow may not choose a gateway before attempting to process payment. - A broken flow may never reach `action_process_payment`. Because of this, MCP must treat edits carefully and avoid making broad changes without a backup and review. --- ## Recommended Default: Create a New Profile Instead of Editing Production If the requested change is large, risky, or structural, MCP should consider recommending a new Payment Profile instead of editing the active one. Create a new profile when: - The existing profile is used in production. - The requested change is a major rewrite. - Gateway routing logic is changing significantly. - Retry or decline logic is changing. - Kill terms are being added or changed. - Function-based routing is being added. - Cross-business/corp routing changes are involved. - The user wants to test before production. Safer approach: ```text Get existing profile → copy settings → create new disabled profile → review/test → switch usage intentionally ``` Use `EditPaymentProfile` directly when: - The edit is minor. - The user explicitly wants to edit this profile. - A backup has been saved. - The new flow has been reviewed. - The risk is understood. --- # Mandatory Backup Workflow Before Editing Before editing a Payment Profile, MCP should always retrieve and save the existing settings. This is required because `EditPaymentProfile` changes payment-processing behavior and there must be a way to inspect, compare, or restore the previous state. --- ## MCP Must Save Existing Settings Locally Before submitting `EditPaymentProfile`, MCP should: 1. Call `GetPaymentProfile` for the target `payment_profile_id`. 2. Save the full existing Payment Profile response locally. 3. Save at least: - `payment_profile_id` - `name` - `description` - `enabled` - `payment_flow` - any additional profile settings returned by `GetPaymentProfile` - timestamp - reason for edit 4. Use a filename that clearly identifies the profile and time. Suggested local backup filename: ```text payment_profile_backup___.json ``` Example backup object: ```json { "backup_type": "payment_profile_before_edit", "backup_created_at": "2026-05-27T12:00:00Z", "profile_version": "v1.2.0", "reason_for_edit": "Change fallback gateway group for renewal routing.", "payment_profile": { "id": "XXXXXXXXXXXXXXXXXXXX", "name": "Primary Credit Card Profile", "description": "...", "enabled": true, "payment_flow": [] } } ``` The MCP’s local backup is not optional. It is the safety reference if the edit causes payment issues. --- ## If a Human User Is Interacting, the User Should Also Save a Local JSON Backup When the MCP is interacting with a human user, it should also instruct the user to save a local JSON backup before changes are made. Recommended user-facing message: ```text Before I edit this Payment Profile, please save a local JSON backup of the current profile settings. Payment Profiles control live credit card routing, and this backup can be used to review or restore the previous configuration if anything behaves unexpectedly. ``` If the MCP can provide a downloadable JSON backup file, it should do so before applying changes. The user should save the file somewhere safe, such as: ```text payment_profile_backup___.json ``` The MCP should not proceed with a risky human-directed edit until the user has had the opportunity to save the backup, unless the user explicitly instructs the MCP to proceed without doing so. --- ## Automated / Non-Interactive Backups If the MCP is running without a human in the loop, a user-facing backup prompt is not required. However, the MCP should still: - Save the current profile settings locally. - Retain a structured before/after diff. - Retain the generated flow representation. - Log why the edit was made. - Create the edit disabled where possible. - Avoid high-risk edits unless explicitly authorized by configuration. Rule: ```text Human in loop = MCP saves backup and tells user to save local JSON backup. No human in loop = MCP saves backup and logs structured before/after state. ``` --- --- # Versioning Requirement Payment Profiles should use consistent versioning in both the Payment Profile description and backup file names. Versioning is important because Payment Profiles may evolve over time as gateway routing, retry logic, filters, Functions, kill terms, or business/corp routing rules change. Consistent versioning helps humans and MCP systems understand: - Which version of the flow is currently active. - Which backup matches which edit. - What changed between edits. - Whether a profile was rolled back. - Whether a user is reviewing the correct profile state. - Which version introduced a routing or processing issue. - Which backup should be used for rollback. --- ## Versioning in Payment Profile Descriptions When editing a Payment Profile, MCP should maintain a clear version marker inside the `description`. Recommended format: ```text Version: v1.0.0 Last Updated: 2026-05-27 Change Summary: Initial production payment flow using Business A Primary Gateway Group with Gateway A as failsafe. ``` Example description: ```text Version: v1.2.0 Last Updated: 2026-05-27 Purpose: Processes initial sales for Business A. Routing: Uses Business A Primary Gateway Group with Gateway A as failsafe. Change Summary: Added fallback retry path for recoverable gateway declines. No kill terms added. ``` MCP should update the version when meaningful changes are made. --- ## Suggested Versioning Pattern Use semantic-style versioning when possible: ```text vMAJOR.MINOR.PATCH ``` Recommended interpretation: | Version Change | Use When | |---|---| | Patch, such as `v1.0.1` | Description-only changes, note updates, small metadata note changes, or non-routing edits. | | Minor, such as `v1.1.0` | Adds or changes a limited flow branch, gateway group, failsafe gateway, retry rule, metadata insertion, or filter. | | Major, such as `v2.0.0` | Major flow rewrite, request-type routing change, Function-based routing, kill-term change, or significant gateway/corp routing change. | MCP should not silently change version numbers. If interacting with a human user, MCP should show the proposed new version in the edit summary. --- ## Versioning in Backup File Names Backup file names should include the current version before the edit. Recommended backup filename format: ```text payment_profile_backup___.json ``` Example: ```text payment_profile_backup_XXXXXXXXXXXXXXXXXXXX_v1.2.0_2026-05-27_14-30-00.json ``` If the current profile description does not contain a version, MCP should either: 1. Add an initial version to the profile description as part of the edit, or 2. Use `unversioned` in the backup filename and recommend adding versioning going forward. Example unversioned backup filename: ```text payment_profile_backup_XXXXXXXXXXXXXXXXXXXX_unversioned_2026-05-27_14-30-00.json ``` --- ## Versioning in Before/After Diffs When showing or logging a proposed edit, MCP should include version movement. Example: ```text Version change: - Current version: v1.2.0 - Proposed version: v1.3.0 Change summary: - Add fallback retry through Business A Backup Gateway Group. - Keep Gateway A as failsafe. - No kill terms added. - No Function nodes added. ``` This should be included in human review prompts and automated logs. --- ## Versioning During Rollback If a rollback occurs, MCP should not erase version history. Recommended rollback description pattern: ```text Version: v1.2.1 Last Updated: 2026-05-27 Purpose: Processes initial sales for Business A. Routing: Restored routing from v1.2.0 backup. Change Summary: Rolled back v1.3.0 due to unexpected decline routing behavior. Rollback Source: payment_profile_backup_XXXXXXXXXXXXXXXXXXXX_v1.2.0_2026-05-27_14-30-00.json ``` This makes it clear that the current profile has been restored from a previous version but is itself a new edited state. --- ## MCP Versioning Rules MCP should follow these rules: 1. Check the current description for a version marker before editing. 2. Include the current version in the local backup filename. 3. Include the proposed new version in the edit summary. 4. Update the description with the new version, last updated date, and change summary when meaningful edits are made. 5. Use consistent version formatting across edits. 6. If no version exists, recommend adding one. 7. If human in the loop, show the version change before submitting `EditPaymentProfile`. 8. If automated, log current version, proposed version, and backup filename. 9. During rollback, include the rollback source backup filename in the description. # Safe Edit Workflow Before editing, MCP should confirm the Payment Profile overview has been reviewed when making broader design or routing decisions. Recommended workflow: 1. Identify the `payment_profile_id`. 2. Call `GetPaymentProfile`. 3. Check the current description for a version marker. 4. Save the current settings locally as JSON using a versioned backup filename. 5. If human in the loop, give the user a versioned local JSON backup to save. 6. Determine whether the change is minor or structural. 7. Decide the proposed new version number and include it in the edit summary. 8. If structural, consider creating a new disabled profile instead of editing the active one. 9. If editing the active profile, consider temporarily disabling it if safe and appropriate. 10. Build the proposed edit. 11. Update the description with the new version, last updated date, and change summary when meaningful edits are made. 12. If editing `payment_flow`, generate a visual or structured flow representation. 13. Validate the new flow. 14. Show the human user the proposed diff, version change, and visual representation if applicable. 15. Ask for approval if human in the loop. 16. Submit `EditPaymentProfile`. 17. Retrieve the profile again with `GetPaymentProfile`. 18. Compare the after-state to the intended edit. 19. Monitor payment behavior if the profile is active. 20. Keep the versioned backup available for rollback or audit. --- # Simple Edits Some edits are lower risk because they do not alter payment-routing logic. ## Rename the Payment Profile ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "name": "Primary Credit Card Profile - Updated" } ``` ## Update Description ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "description": "Processes standard initial sales through the Primary Gateway Group. Uses Gateway A as failsafe." } ``` ## Disable the Profile ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "enabled": false } ``` ## Enable the Profile ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "enabled": true } ``` Important: Even enabling or disabling can affect payment processing if products, subscriptions, trials, or checkout flows depend on the profile. --- # High-Risk Edits The following changes are high risk and require extra review: - Replacing the full `payment_flow`. - Removing or changing `action_choose_gateway`. - Removing or changing `action_process_payment`. - Adding retry logic. - Changing decline paths. - Adding or changing kill terms. - Adding `action_custom_function`. - Changing Function run method. - Adding or removing `action_abort_flow`. - Changing gateway response filters. - Changing request type filters. - Changing attempt-count filters. - Changing process-payment-count filters. - Changing gateway groups. - Changing failsafe gateways. - Changing business/corp gateway routing. - Changing metadata filters. - Changing customer group filters. - Changing currency or campaign routing. MCP should require explicit user confirmation for high-risk edits when a human is in the loop. --- # Editing `payment_flow` `payment_flow` is the most important and most dangerous editable field. A payment flow determines how credit card payment requests are routed and processed. The flow should always be designed so every path intentionally does one of these: 1. Chooses a gateway and processes payment. 2. Aborts intentionally. 3. Returns a deliberate decline/error result after a payment attempt. A path that accidentally stops before gateway selection or before payment processing can break checkout. --- ## Minimum Flow Requirements Every valid payment-processing flow should include: | Node Type | Purpose | |---|---| | `start_payment_request` | Begins the payment flow. | | `action_choose_gateway` | Selects a gateway or gateway group. | | `action_process_payment` | Processes the payment through the selected gateway. | Rules: - Only one `start_payment_request` node should exist. - `start_payment_request` has no inputs. - A gateway should be chosen before `action_process_payment`. - `action_process_payment` `output_1` means success. - `action_process_payment` `output_2` means decline or error. - If a payment declines and `output_2` is not connected, the flow ends and returns the decline. - If a payment declines and `output_2` is connected, the flow continues through retry, filter, Function, or abort logic. --- # Prefer Gateway Groups Over Individual Gateways When editing `action_choose_gateway`, gateway groups should generally be preferred over individual gateways as the selection source. Best practice: ```text Use selection_source = gateway_group whenever possible. ``` The reason is operational safety. A single RevCent account may contain gateways for multiple businesses, brands, stores, corporations, merchant accounts, or processing strategies. Gateway groups allow gateways to be organized so the correct business or corporation uses the correct gateways and avoids using gateways that belong to another business/corp inside the same RevCent account. Gateway groups help prevent: - Business A routing through Business B’s gateway. - A campaign using a merchant account intended for another brand. - Subscription renewals using gateways meant only for initial sales. - International traffic using domestic-only gateways. - High-risk traffic using low-risk gateways. - A fallback route selecting a gateway that does not belong to the relevant business/corp. MCP should ask: ```text Which gateway group should this business/corp use for this payment path? ``` rather than immediately asking for individual gateway IDs. Use individual gateways only when: - The user explicitly wants a specific gateway. - The profile has only one valid gateway. - A specific failsafe gateway must be set. - A Function or gateway-response path intentionally selects one known gateway. - The user explicitly confirms the gateway belongs to the correct business/corp route. --- # Failsafe Gateway Requirement An `action_choose_gateway` node should almost always have a failsafe gateway configured. Gateway selection can fail when: - All selected gateways are disabled. - Gateway group selection produces no eligible enabled gateway. - Revenue or time rules exclude all selected gateways. - Preference/exclusion rules eliminate available gateways. - Last-approved or last-declined selection has no matching gateway. - Gateway conditions change after the profile is edited. Without a failsafe gateway, if `action_choose_gateway` cannot select a gateway, the flow immediately terminates and returns an error instead of attempting the payment through a safe fallback. Recommended rule: ```text Every action_choose_gateway node should include a failsafe gateway unless the user explicitly confirms no fallback gateway should be used. ``` Failsafe gateway should be: - Valid and enabled. - Appropriate for the request type. - In the same business/corp routing context. - Able to process the relevant currency/card/payment type. - Reviewed before edit approval. Avoid: ```text Gateway Group: Business A Primary Gateways Failsafe Gateway: Business B Gateway ``` unless the user explicitly confirms cross-business/corp fallback is intentional. --- # `output_1`, `output_2`, and `output_3` Use output names exactly. Do not describe outputs as colors. | Output | Meaning | |---|---| | `output_1` | Success / passed / true path, depending on node type. | | `output_2` | Decline / error / failed / false path, depending on node type. | | `output_3` | Used by `filter_merge_filters` to connect filter nodes into an AND condition. | Examples: - `action_process_payment.output_1`: payment succeeded. - `action_process_payment.output_2`: payment declined or gateway error occurred. - `filter_currency.output_1`: currency condition matched. - `filter_currency.output_2`: currency condition did not match. - `action_custom_function.output_1`: Function executed successfully. - `action_custom_function.output_2`: Function errored or timed out. --- # Consequences of Specific Flow Edits ## Editing Gateway Selection Changing gateway selection can: - Move traffic to different merchant accounts. - Affect processing volume distribution. - Break business/corp routing. - Change approval rates. - Increase gateway declines. - Trigger gateway volume/risk issues. - Route transactions to gateways with different currencies or rules. Always verify: - Correct gateway group. - Correct failsafe gateway. - Correct selection method. - Correct business/corp ownership. - Correct request type. --- ## Editing Retry Logic Changing retry logic can: - Increase gateway attempts. - Increase customer-facing decline count. - Increase gateway risk. - Cause hard declines to retry. - Cause soft declines not to retry. - Create loops if process-payment count is not checked. - Affect max attempts behavior. Use: - `filter_process_payment_count` - `filter_gateway_response` - abort paths - limited retry routes Do not create unbounded retry loops. --- ## Editing Gateway Response Filters Gateway response filters can route based on decline or error text. Changing them can: - Abort recoverable declines. - Retry hard declines. - Miss important gateway response text. - Return the wrong custom error. - Alter chargeback/fraud handling. MCP must not invent gateway response terms. The user should provide the exact terms or they should come from known account/gateway data. --- ## Editing Kill Terms Kill terms stop the payment flow if a declined gateway response contains specific words or phrases. Kill terms are powerful and risky because they can stop a payment flow and may cancel/void the related sale. Rules: - The user must explicitly state any kill terms. - MCP must never invent, infer, guess, or auto-generate kill terms. - MCP must warn the user if a provided kill term appears too broad or likely to cause false positives. - MCP must require confirmation before including broad terms. - If no explicit user-provided kill term exists, use no kill term. Potentially dangerous broad terms include: ```text the and card declined error failed invalid payment do not honor insufficient ``` Example warning: ```text You provided `declined` as a kill term. This may be too broad because many gateway responses contain the word declined, including recoverable soft declines. Including it could cause the payment flow to stop and potentially cancel/void sales more often than intended. Do you still want to include `declined` as a kill term? ``` --- ## Editing Custom Function Nodes `action_custom_function` is advanced and should be used carefully. Changing Function nodes can: - Add latency to checkout. - Cause payment processing to wait on external logic. - Fail or timeout. - Route payments incorrectly. - Set the wrong gateway. - Return unsafe custom errors. - Block payment processing if `output_2` fallback is not connected. If a Function uses wait-for-response: - Add `output_2` fallback. - Keep execution fast. - Avoid slow third-party APIs where possible. - Define exactly what the Function returns. - Define what happens on timeout. - Confirm the Function should run inside the payment flow. --- ## Editing Metadata Nodes `action_insert_metadata` runs on the side and has no outputs. Risk: If MCP connects only to metadata insertion and forgets to continue the main path, the flow may not proceed to payment processing. When editing metadata: - Confirm metadata names and values. - Confirm metadata should be inserted on the intended item. - Confirm the main payment path continues separately. - Do not use metadata nodes as the only continuation path. --- # Visual Payment Flow Review for User-Interactive Edits When the MCP is interacting with a human user and the edit affects `payment_flow`, it should show a visual representation of the before and after flow. This helps the user review and approve or request changes. Show: 1. Existing flow. 2. Proposed edited flow. 3. Plain-language summary of changes. 4. Risks introduced by the edit. 5. Failsafe gateway for every choose-gateway node. 6. Retry and abort behavior. 7. Function fallback behavior. 8. Kill terms and warnings, if any. If the MCP is fully automated without a human in the loop, a user-facing visual is not required, but the MCP should still save a structured representation of the before and after flow for audit. --- ## Recommended Mermaid Before/After Format Example proposed flow: ```mermaid flowchart TD START[start_payment_request] -->|output_1| GATEWAY[action_choose_gateway
Primary Gateway Group
Failsafe: Gateway A] GATEWAY -->|output_1| PROCESS[action_process_payment] PROCESS -->|output_1 success| SUCCESS[Payment Approved
Flow Ends] PROCESS -->|output_2 decline/error| ABORT[action_abort_flow
Return Decline/Error] ``` Recommended review prompt: ```text Please review the before/after payment-flow diagram. This edit affects real payment routing. Confirm that the gateway groups, failsafe gateways, retry behavior, abort paths, and Function behavior are correct, or tell me what to change before I edit the Payment Profile. ``` --- ## ASCII Fallback If Mermaid is not available, show a plain text flow. ```text [start_payment_request] | | output_1 v [action_choose_gateway] - Gateway Group: Primary Gateways - Failsafe: Gateway A | | output_1 v [action_process_payment] | | output_1 success v [Success / Approved] [action_process_payment] | | output_2 decline/error v [action_abort_flow / Return Decline] ``` --- # Diff Review Requirement When editing, the MCP should show a human-readable diff of changes. Example: ```text Proposed changes: - Version change: v1.2.0 → v1.3.0. - Update description with new version, last updated date, and change summary. - Change selection_source on node `choose_gateway_1` from `gateway` to `gateway_group`. - Replace gateway ID `AAAAAAAAAAAAAAAAAAAA` with gateway group `BBBBBBBBBBBBBBBBBBBB`. - Add failsafe gateway `CCCCCCCCCCCCCCCCCCCC`. - Keep process payment success path unchanged. - Route payment decline output_2 to existing abort node. - No kill terms added. - No Function nodes added. ``` If the edit is automated, this diff should be stored in logs. --- # Automated / Non-Interactive Editing If no human user is in the loop, the MCP should still: 1. Save a local JSON backup. 2. Use a versioned backup filename. 3. Store a before/after diff including version movement. 4. Store a structured flow representation. 5. Validate the edited flow. 6. Avoid broad, risky edits unless authorized by configuration. 7. Never invent kill terms. 8. Prefer gateway groups over individual gateways. 9. Ensure failsafe gateways exist. 10. Create or keep the profile disabled unless automation is authorized to enable it. 11. Log the reason for the edit. --- # Rollback Guidance If an edit causes issues, rollback should use the saved backup. Recommended rollback process: 1. Retrieve the backup JSON. 2. Confirm it belongs to the correct `payment_profile_id`. 3. Compare current profile against backup. 4. Submit `EditPaymentProfile` with the previous backed-up values. 5. Retrieve the profile again with `GetPaymentProfile`. 6. Confirm settings match the backup. 7. Monitor payment processing. Rollback request concept: ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "name": "Backed Up Name", "description": "Backed up description", "enabled": false, "payment_flow": [] } ``` Important: - Do not blindly restore if the profile was changed again after the backup. - Confirm rollback is still appropriate. - Consider disabling first if payment behavior is actively broken. --- # MCP Questions Before Editing a Payment Profile Before editing, MCP should confirm: ```text Has the Payment Profile overview been reviewed? ``` Before editing, MCP should ask: 1. What Payment Profile should be edited? 2. Is this profile currently active in production? 3. What exactly needs to change? 4. Should a new disabled profile be created instead of editing this one? 5. Has the current profile been backed up locally? 6. If human in the loop, has the user saved a versioned local JSON backup? 7. What is the current version, and what should the proposed new version be? 8. Which request types should the edited profile support? 9. Which gateway groups should be used for each business/corp route? 10. Are any individual gateways explicitly required? 11. What failsafe gateway should be used for each choose-gateway node? 12. Should gateway selection use `evenly_distribute`, `random`, `round_robin`, or `sort_order`? 13. Are campaign, currency, card type, amount, product group, metadata, or customer group filters changing? 14. Is retry behavior changing? 15. How many process-payment attempts are allowed in a single flow? 16. Are gateway response terms changing? 17. Are kill terms changing? If yes, what exact user-provided terms? 18. Are any provided kill terms broad enough to require a warning? 19. Is a custom Function being added or changed? 20. What should happen if the Function fails or times out? 21. Are metadata insertions changing? 22. Are abort/custom error paths changing? 23. Should the profile remain disabled after editing? 24. Has the user approved the before/after visual flow if human in the loop? --- # Validation Checklist Before Submitting `EditPaymentProfile` 1. Existing profile was retrieved with `GetPaymentProfile`. 2. Existing settings were saved locally as versioned JSON. 3. If human in the loop, the user was told to save a versioned local JSON backup. 4. If human in the loop and `payment_flow` changed, before/after visual flow was shown. 5. If automated, structured before/after flow representation was logged. 6. Current version and proposed new version were identified. 7. User or automation explicitly authorized the edit. 8. There is exactly one `start_payment_request`. 9. Every node ID is unique. 10. Every connection references an existing node. 11. Every non-start node has `input_1`. 12. Start node has no inputs. 13. Gateway groups are preferred over individual gateways unless individual gateways are explicitly required. 14. Every gateway group belongs to the intended business/corp routing context. 15. Every individual gateway, if used, was explicitly requested or confirmed. 16. Every gateway group ID exists. 17. Every individual gateway ID exists. 18. Every `action_choose_gateway` node has a failsafe gateway unless explicitly omitted. 19. Failsafe gateways belong to the correct business/corp routing context. 20. Choose Gateway happens before Process Payment. 21. Every Process Payment node has intentional `output_1` and `output_2` behavior. 22. Retry paths are limited. 23. Decline paths retry, abort, or intentionally end. 24. Filter priorities are intentional. 25. Merge filters only connect filter nodes through `output_3`. 26. Insert Metadata nodes do not accidentally stop the main flow. 27. Function nodes have `output_2` fallback if using wait-for-response. 28. Function timeout behavior is safe. 29. Abort flow paths are intentional. 30. Custom errors are customer-safe. 31. Kill terms, if used, were explicitly provided by the user. 32. Broad user-provided kill terms were warned about and confirmed before inclusion. 33. Max attempts behavior is understood. 34. Description includes consistent versioning, last updated date, and change summary when meaningful edits are made. 35. The profile remains disabled after edit unless enabling is explicitly intended. 36. Post-edit `GetPaymentProfile` verification is planned. --- # Example: Edit Description Only ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "description": "Processes initial sales through the Business A Primary Gateway Group with Gateway A as the failsafe gateway." } ``` --- # Example: Disable Before Structural Edit ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "enabled": false } ``` --- # Example: Structural Flow Edit Concept This is a conceptual example only. Use real gateway group and gateway IDs. ```json { "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "payment_flow": [ { "id": "start", "type": "start_payment_request", "inputs": {}, "outputs": { "output_1": { "connections": [ { "node": "choose_primary_gateway_group", "output": "input_1" } ] } }, "node_settings": { "node_note": "Start payment request." } }, { "id": "choose_primary_gateway_group", "type": "action_choose_gateway", "inputs": { "input_1": { "connections": [ { "node": "start", "input": "output_1" } ] } }, "outputs": { "output_1": { "connections": [ { "node": "process_payment", "output": "input_1" } ] } }, "node_settings": { "selection_source": "gateway_group", "selection_method": "evenly_distribute", "gateway_groups": [ "YYYYYYYYYYYYYYYYYYYY" ], "node_note": "Choose from the Business A primary gateway group. Failsafe gateway should be configured according to the current schema/account settings." } }, { "id": "process_payment", "type": "action_process_payment", "inputs": { "input_1": { "connections": [ { "node": "choose_primary_gateway_group", "input": "output_1" } ] } }, "outputs": { "output_1": { "connections": [] }, "output_2": { "connections": [] } }, "node_settings": { "node_note": "Process payment. Success ends the flow. Decline returns the gateway response." } } ] } ``` Important: - Prefer gateway groups. - Configure a failsafe gateway according to the current schema/account settings. - Do not use placeholder IDs. - Do not submit structural edits without backup and review. --- # Output Schema A successful `EditPaymentProfile` response returns: ```json { "api_call_id": "XXXXXXXXXXXXXXXXXXXX", "api_call_unix": 1740000000, "code": 1, "payment_profile_id": "XXXXXXXXXXXXXXXXXXXX", "result": "..." } ``` Fields: | Field | Description | |---|---| | `api_call_id` | 20-character API call ID. | | `api_call_unix` | Unix timestamp when the API call was initiated. | | `code` | Response code. `1` indicates success. | | `payment_profile_id` | 20-character Payment Profile ID that was edited. | | `result` | Human-readable result message. | --- # Quick Reference Before editing: ```text GetPaymentProfile → identify current version → save versioned local JSON backup → user saves versioned backup if human in loop → choose proposed version → build edit → show versioned diff/visual if human in loop → validate → EditPaymentProfile → GetPaymentProfile verify ``` Most important rules: ```text Do not edit without a versioned backup. Do not invent payment logic. Prefer gateway groups over individual gateways. Every choose-gateway node should almost always have a failsafe gateway. Never invent kill terms. Warn before including broad user-provided kill terms. Show visual review only when human in the loop. Consider creating a new disabled profile instead of editing production. ``` --- # Overview Reference AI/MCP should read the Payment Profile overview for broad conceptual understanding before creating, editing, or deeply reviewing Payment Profiles: ```text https://revcent.com/documentation/markdown/mcp/operation/OverviewPaymentProfile.md ``` --- Document Parent Directory * [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.