Payment Route Optimizer

Build payment-routing diagnostics, route matrices, retry and failover policies, rollout guardrails, and merchant-friendly planning briefs for payment, checko...

Security Scan

The skill's code and runtime instructions match its stated purpose (offline payment-routing planning) and do not request unrelated credentials, network access, or live changes.

Purpose & Capability

Name/description align with the implementation: handler.py parses user text and emits an offline routing brief. No unrelated environment variables, binaries, or cloud credentials are requested.

Instruction Scope

SKILL.md stays within an offline planning remit and explicitly forbids live routing or raw PAN handling. However it invites user-supplied 'payment-log summaries or pasted findings' — users could accidentally paste sensitive card data. The skill code itself only processes text locally and does not send data externally, but operators should avoid pasting raw PANs or other secrets.

Install Mechanism

There is no install spec (instruction-only) which minimizes install risk. The package nevertheless includes two local Python files (handler.py and tests). Those files perform only local text parsing and rendering; there are no downloads, network calls, or extracted archives. Review local code before running if provenance is a concern.

Credentials

The skill declares no required environment variables, credentials, or config paths and the code does not read env vars or secrets. Requested permissions are proportionate to the stated task.

Persistence & Privilege

always:false and default autonomous invocation are set. The skill does not request permanent presence or modify other skills or system-wide settings.

Assessment

This skill appears coherent and low-risk for offline planning, but consider these precautions before enabling it: (1) Do not paste raw PANs, full card numbers, CVV, or other unmasked payment data into prompts — redact or tokenize before use. (2) The package has no network calls, but provenance is limited (source/homepage unknown); if this matters to you, inspect handler.py locally and run the included tests in a safe environment. (3) Treat outputs as planning advice only: follow your compliance, PCI, and legal review processes and require human approval before any production routing changes. (4) If you plan to run this in an automated agent, consider limiting the agent's ability to forward user-provided payment text to external endpoints.

Overview

Use this skill to turn payment-operations context into an offline routing strategy brief. It is best for merchants and product teams that need clearer routing logic, safer failover planning, and a readable rollout package.

This MVP is planning-oriented. It does not switch live traffic, move money, inspect raw PAN data, or replace compliance review. It translates merchant goals into route candidates, retry guardrails, and implementation notes.

Trigger

Use this skill when the user wants to:

• improve authorization rate or payment success rate
• reduce payment processing cost without blindly sacrificing approval
• compare PSPs, acquirers, local methods, or failover setups
• prepare a routing policy review, outage plan, or market-launch payment strategy
• generate a rollout checklist for engineering, finance, or payment ops

Example prompts

• "Help me improve card authorization in Brazil"
• "Create a payment failover plan before peak season"
• "We need a routing matrix that balances approval and fee cost"
• "Turn these PSP notes into a rollout playbook"

Workflow

1. Capture the objective, markets, payment methods, and major constraints.
2. Normalize the current routing question into approval, cost, risk, or balanced mode.
3. Generate segment-level route candidates and backup paths.
4. Add retry rules, failover guardrails, and rollout sequencing.
5. Return a markdown planning brief for review by product, finance, and engineering.

Inputs

The user can provide any mix of:

• payment-log summaries or pasted findings
• PSP, acquirer, local method, or fee-sheet context
• market, currency, issuer, BIN, device, or amount-band concerns
• goals around authorization, cost, fraud, 3DS friction, or resilience
• rollout constraints, such as human approval, engineering bandwidth, or peak-season risk

Outputs

Return a markdown brief with:

• routing objective and planning mode
• baseline diagnostic
• suggested route matrix
• retry and failover policy
• rollout plan
• monitoring guardrails
• compliance and limitation notes

Safety

• Do not claim to execute live routing changes.
• Keep raw card data out of scope and assume only masked or tokenized inputs.
• Treat compliance, PCI, fraud, and chargeback review as external control layers.
• Require human approval before any production policy is adopted.

Examples

Example 1

Input: merchant wants better card approval in Brazil and Europe with two PSPs.

Output: recommend a segment-level routing matrix, one-retry rule for soft declines, and a staged rollout with market-specific monitoring.

Example 2

Input: payment team wants an outage fallback plan before peak season.

Output: generate timeout, soft-decline, and provider-outage failover guidance with rollback triggers.

Acceptance Criteria

• Return markdown text.
• Include diagnosis, route matrix, retry or failover guidance, and rollout sections.
• Keep the output readable for non-engineers.
• Make the offline and approval-required boundary explicit.