Connect with AI
Give your agent one message. It reads your project, connects Yolfi, and adds verified payment handling.
Copy one message
Send this to the assistant working on your product:
Add Yolfi payment links to my product. Follow the documentation: https://docs.yolfi.com/aiYour agent handles the integration and chooses a connection supported by its environment. You complete account sign-in or consent when needed and supply business details that are not already available. Account authorization does not require sharing a password, wallet private key, seed phrase, or API key in chat.
What the conversation looks like
This is an example conversation, not a completed payment:
| You | Your assistant |
|---|---|
| Add Yolfi payment links to this app using its existing products and prices. | I will read the Yolfi guide and inspect your product, pricing, checkout, and payment configuration first. I will reuse the existing details and any matching payment links. If account authorization or another required detail is missing, I will explain exactly what is needed. Then I will add the checkout and verified payment handling, run the available checks, and show you the changes and any remaining steps before launch. |
For a recurring plan, customers receive renewal reminders and make each renewal payment from their own wallet. Do not assume that Yolfi can automatically debit a wallet.
What your assistant needs
| Assistant capability | What it can do |
|---|---|
| Project files and development tools | Inspect the app, implement checkout and verified payment handling, and run local checks. Account operations also require an authorized Yolfi connection. |
| Authorized Yolfi payment tools, without project access | Inspect the workspace and create or reuse payment links within its permissions. It cannot edit your app without access to its files. |
| Chat without file access or connected tools | Read documentation and help you plan or draft an integration. It cannot install a connection, modify your app, or create a real payment link on its own. |
The available tools depend on your client, plan, workspace settings, and permissions. Reading a documentation URL does not automatically connect an account. If your assistant needs additional client configuration, it should explain that step or point your developer to the connection reference.
Decisions you keep
You choose the product, price, currency, payment schedule, and receiving wallets. You approve the account connection in Yolfi and any changes to payment settings. For a new account, you confirm the email address and project name and complete the email or browser authorization step yourself.
Yolfi is non-custodial. Your assistant does not need a private key or seed phrase to configure receiving addresses. Keys and webhook signing secrets belong in your application's secret storage, not in a chat transcript or committed source file. Removing payment links, revoking credentials, and other destructive changes require explicit owner approval.
Review the result
Ask the assistant to show the checkout it added, how the application recognizes a confirmed payment, and the checks it actually ran. Have it explain any missing account configuration or test limitations. A verified webhook or a payment-status check is payment evidence; a frontend redirect is not.
Instructions for the agent
Follow the workflow below. Read a linked reference only when the next operation needs it; you do not need to load the whole documentation. Use the current MCP tool schemas or CLI help for available operations. Linked API references also describe request fields; reading them does not require switching away from a working MCP connection.
1. Inspect before asking
Read the current project and the user's request. If the project is unavailable, ask the owner to open or provide access to it; continue any independent checks your environment supports. Find products, prices, currencies, payment schedules, checkout UI, server routes, existing payment providers, webhook handlers, fulfillment or access logic, and secret-storage conventions. Reuse facts already supplied by the user or present in the project. Do not ask the owner to choose MCP, CLI, or an authentication protocol.
2. Choose and verify a connection
- Inspect your available tools and existing Yolfi configuration. If Yolfi tools are already connected, call
yolfi_auth_statusthrough that connection and check the returned organization before provisioning anything. Once authenticated, continue through those MCP tools. Do not request, generate, retrieve, or configure an organization API key, or start a separate CLI login, just to continue MCP operations. - If no connection exists and your host can configure remote MCP with OAuth, connect to
https://app.yolfi.com/mcpusing the host's supported controls. Let the owner complete browser sign-in and consent, then callyolfi_auth_statusin that same host. - If host OAuth is unavailable but you can run local commands, use the local CLI browser setup. Run setup, open its returned
loginUrl, wait for owner authorization, complete check-in, and verifynpx -y @yolfi/agent auth:status. Continue through the CLI; installing a local MCP server is optional. - If neither route is available, explain the exact missing capability and give the owner the smallest supported connection step from the connection reference. Continue independent project inspection when access is available. Do not claim that reading a URL or adding configuration established a working connection.
Use the capabilities of the current session, not the agent's brand name, to choose a route. Project file access and account tool access are separate. A successful CLI auth check does not authenticate a remote MCP host, and the reverse is also true. Do not start a second signup or connection when an existing one works.
3. Reuse account configuration
Read the authorized organization, settlement configuration, and existing Paylinks. If the product needs payment events, also inspect existing webhook endpoints. Match resources against the requested product, amount, currency, cadence, destination, and endpoint before creating them. Paginate lists when necessary. After an ambiguous create result or timeout, inspect existing state before retrying.
Ask only for required information you cannot find or resolve, such as a receiving address for an unconfigured network or an ambiguous price. Batch related questions. Reuse existing business choices; obtain approval for an actual change to receiving wallets, prices, billing terms, or destructive operations. Do not invent those values. Settlement updates must preserve networks outside the requested change.
4. Implement the requested payment flow
- For a fixed-price product or plan, reuse or create a Paylink and add its hosted URL,
https://pay.yolfi.com/{paylinkId}, to the existing checkout. See Paylink fields when needed. If payments must be matched to an order or customer, read the checkout parameters and trust rules. A public Paylink redirect does not need a private API key in the application. - For a dynamic cart or order total, calculate the amount on the merchant server and create a Checkout Session with a stable idempotency key. Inspect the available tool schema or CLI
helpbefore choosing a command. - If the product must automatically update orders or access after payment, reuse its existing payment-event handling or configure a webhook when needed. Implement raw-body signature verification and durable idempotency for webhook handlers. A request to add only a hosted payment link does not require a new webhook. The webhook recipe is optional implementation guidance.
- Recurring Paylinks send renewal reminders; customers authorize each renewal payment from their own wallet. Do not implement automatic wallet debits. A payment confirmed after the subscription becomes overdue does not automatically restore access or extend its period; follow the subscription lifecycle rules and preserve the merchant's manual-resolution policy.
Only if the application itself makes private HTTP requests, configure a server credential using the API authentication guidance. The host's MCP OAuth token cannot be reused for those HTTP requests. Store any required server credentials or webhook signing secrets using the project's secret manager or ignored local environment files, never a chat transcript or committed source file.
If you create or rotate a webhook endpoint through remote MCP, its one-time signing secret is a sensitive tool result. MCP cannot configure the receiver's secret store by itself. If your host cannot securely write that store, report the precise remaining handoff instead of claiming the integration is ready. Do not repeat the secret in the user-facing response.
5. Verify and finish
Run the relevant project checks and verify the rendered checkout destination. If webhook handling is part of the integration, test valid and invalid signatures with fixture secrets. Verify account operations through the same transport you will use. Before automatic fulfillment, require public payment status = SUCCESS or a verified payment.confirmed event, while respecting subscription state for recurring access. A browser redirect, a Checkout Session marked COMPLETED, isFullyPaid, or deposit confirmation progress is not proof of completed payment.
Show the implemented flow, reused or created resource IDs, checks actually run, and any specific launch dependency such as deployment secret configuration. Do not stop at an account-readiness summary when you have the access and authorization to implement the request. Do not claim a connection, deployment, or live payment was verified when it was not.
Focused references
Use the index only if a needed reference is missing above.
Earlier setup links
Connection verification and recovery.