agentic-payments-due-diligence

Agentic Payments Due Diligence

Use this skill for product, legal-operational, and architecture research involving agent-controlled cards, wallets, tokenized payment credentials, or delegated checkout.

Required output

Return:

1. Exact provider and product identification, including similarly named alternatives.
2. Issuer/program manager/legal entity where publicly disclosed.
3. Card or credential type and exact flow of funds.
4. CLI, REST API, MCP, OAuth, hosted-browser, and browser-agent support.
5. KYC/KYB, age/residency, business ownership, beneficial-owner, and production-underwriting requirements.
6. Merchant, MCC, geographic, recurring-payment, and prohibited-use restrictions.
7. Consent and revocation controls at account, app, budget, card, and purchase levels.
8. Target merchant onboarding, authentication, payment, and API-key model.
9. A separate legal/contractual assessment and practical/technical assessment.
10. Exact URLs, short quotations, contradictions, unknowns, and a safe reference architecture.

State the research date. If the user said not to sign up or transact, do not create accounts, submit identity data, enroll cards, or initiate payment.

Workflow

1. Disambiguate the product before evaluating it

Search the exact name, spelling variants, TLDs, company names, npm packages, official documentation, and issuer agreements. Do not assume the highest-ranked search result is the intended product.

Rank candidates using workflow fit:

• Does the product use a prefunded wallet or a hold on an existing card?
• Does it publish an integration for the named agent framework?
• Was it the subject of a recent launch that explains the user's wording?
• Is it operational, private beta, or only a waitlist?

Give a confidence-ranked conclusion rather than silently collapsing distinct products.

2. Build an official-source evidence stack

Prefer, in order:

1. Cardholder agreement, terms, privacy notice, prohibitions list, and issuer disclosures.
2. Current API/MCP/CLI documentation and machine-readable docs indexes.
3. Provider-hosted product pages and provider-issued announcements.
4. Payment-network documentation for network-level claims.

Use third-party reporting only to locate official material, not as final evidence when official sources exist.

When a documentation site exposes llms.txt, an OpenAPI document, raw Markdown, or JSON, fetch it and search it for endpoints and omitted capabilities. A public endpoint list is useful negative evidence: for example, a billing API that only reads balances is not proof of a credit-purchase API.

3. Reconcile marketing, docs, and legal terms

Create a contradiction ledger. Compare:

• Product page vs. quickstart/API reference.
• FAQ vs. current operational docs.
• Marketing labels such as “prepaid” or “debit” vs. the cardholder agreement's legal characterization.
• Launch announcements vs. feature flags, beta limits, and network deployment disclaimers.

Prefer specific, current operational and legal documents over generic FAQ copy. Quote both sides when the conflict materially changes KYC, limits, funding, availability, or user control. Treat provisional or unfinished terms as a production blocker, not a minor footnote.

4. Trace money and authority separately

Draw two paths:

Money path: user funding source → provider wallet/hold/collateral → issued or tokenized credential → merchant processor → target credits/service.

Authority path: human account owner → provider OAuth/consent/KYC → agent session/token → card issuance approval → merchant account acceptance → checkout authorization.

Do not call a flow “user funded” until identifying whether it is:

• A prefunded custodial or onchain balance.
• A collateralized credit line.
• A temporary hold on a saved payment card.
• Direct use of a connected card through network tokenization.
• A company-funded pooled wallet.

5. Analyze the target merchant independently

Verify from official merchant sources:

• Signup methods: email, Google/GitHub OAuth, SSO, or API.
• Who accepts the merchant's terms and owns the account.
• Personal/team/organization account structure.
• Card/ACH support, prepaid-credit model, expiration/refund terms, and processor handoffs.
• Whether account creation or buying credits has a documented API.
• API-key creation, scopes, team roles, and official MCP support.

A payment card does not solve identity onboarding. If a merchant only supports third-party OAuth, an agent-provided email address cannot create the account by itself.

6. Decide legality and practicality separately

Use cautious language; this is operational research, not legal advice.

• Provider permission: Does the payment product expressly permit an AI agent to act for a verified human?
• Merchant contract: Does the merchant require the human to sign in, accept terms, keep credentials private, or avoid unapproved automation?
• Technical feasibility: Can the current API/browser flow complete signup and checkout without unsupported identity creation, CAPTCHA bypass, credential sharing, or hidden human steps?

A safe conclusion may be: “agent-assisted payment is practical, but fully autonomous legal account creation is not supported.” Do not turn contractual ambiguity into a categorical legal claim.

7. Design for least authority

Default architecture:

1. Human-owned merchant identity and explicit terms acceptance.
2. Hosted KYC/funding/OAuth handoffs; the agent never receives ID, SSN, real funding-card PAN, passkeys, or passwords.
3. Versioned authorization containing merchant, purpose, exact amount, account, expiry, and whether recurrence is allowed.
4. Determine the final checkout total before creating a credential.
5. Single-use, exact-cap credential for one-time purchases; merchant-scoped token only when supported and explicitly selected.
6. Fresh confirmation immediately before destructive checkout.
7. Isolated browser context; inject PAN/CVV only into the payment form; redact chat, logs, traces, analytics, and support messages.
8. Stop and hand off on CAPTCHA, KYC, 3DS/passkey, AVS mismatch, decline, or material price change.
9. Verify both payment transaction and merchant balance/service activation; close unused credentials.
10. Create a least-privilege merchant API key and store it in a user-owned secret vault; use official APIs/MCP afterward instead of retaining the browser login.

Never respond to a decline by autonomously minting multiple replacement cards.

Pitfalls

• Treating two identically named products as one.
• Repeating “prepaid virtual card” when the agreement says collateralized credit.
• Assuming “works with any merchant” means the merchant or processor accepts the BIN.
• Assuming an AI-lab merchant allowlist includes every AI company.
• Equating a product's built-in buying-agent merchant list with raw-card acceptance.
• Assuming an agent email can satisfy Google/GitHub/SSO onboarding.
• Claiming a public read-only billing API can buy credits.
• Hiding public-doc conflicts instead of presenting them.
• Letting a provider's agent-friendly terms override the target merchant's account rules.

Verification checklist

Before finalizing:

• [ ] Candidate products and TLDs were disambiguated.
• [ ] Legal entity and issuer were identified or marked unknown.
• [ ] Funding and settlement paths were stated exactly.
• [ ] KYC/KYB and ownership unknowns were not guessed.
• [ ] Merchant and geography restrictions were checked.
• [ ] Consent, approval, revocation, and spend limits were separated.
• [ ] Target merchant signup and billing APIs were independently verified.
• [ ] Contradictory official claims were quoted.
• [ ] Legal and practical conclusions were separated.
• [ ] Architecture preserves human contract acceptance and least authority.
• [ ] No prohibited signup or transaction was performed.

References

• references/agentcard-fal-july-2026.md — condensed official-source findings and reusable provider quirks from the AgentCard/fal.ai investigation.