Papaya Pay Any Bill (USA)
Ready for a new way to bill pay?
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data
What it can do
- Analyze Bill: Read a bill from the user's description and create it for payment. This is the first step. Capture every address and identifier on the bill (remit-to address, account/invoice number, any
- Check Payment Method: Optional: check whether the user has finished the secure form and a card is on the bill yet. Returns the card's last 4 digits and name when one is set, or a PENDING status when t
- Confirm Payment Intent: Final step: submit the bill for payment, after a card has been set. You must have confirmed the amount with the user first (amount_to_pay may be partial) and quote their confir
What data it sees
Do you need an account
No: the server works without sign-in
Ready for a new way to bill pay? Pay any bill in a snap, right from a chat. Describe or snap a photo of your bill (electric, water, gas, internet, phone, medical, credit card, rent, parking tickets, traffic violations and more) and Papaya reads it, then hands you a secure link to pay by card. Fast, secure, and no juggling twelve logins, with full or partial payments and status updates.
Powered by Papaya (papayapay.com/payabill). Note: Only available to users in the USA If you get blocked via Smithery you can direct connect using the mcp url: https://mcp-agent.consumer-production.papayapay.com/payagent/mcp
Server tool list (6)
Raw names from tools/list. Only developers need these.
| analyze_bill | Read a bill from the user's description and create it for payment. This is the first step. Capture every address and identifier on the bill (remit-to address, account/invoice number, any code or pin) - missing details can delay or fail the payment. The remit-to address (where payment is sent) is especially important: it is what identifies the correct biller, and a wrong or missing one can match the bill to the wrong biller and cause a failed or delayed payment. Always include it. If the bill does not show a remit-to address, research the biller's official remit-to / payment address online and use that rather than omitting it. For the same reason, capture the bill's online-payment URL in payUrl and any payment phone number in otherInfo whenever the bill shows them - these strongly identify the correct biller. Before calling, ask the user how much they want to pay (the full balance amountDue, or a partial amount), then pass it as amount_to_pay and quote what they said in user_amount_statement - both are required (never invent the amount). If the payment carries a fee, the result includes a `fees` list - show any returned fee to the user before continuing. The result also includes a `payment_link`: give this link to the user as-is so they can enter their card on the secure form (the only way to set a payment method). If the user already exists from a prior bill, pass their user_id and auth_token to reuse the account. Args: bill_description: structured bill details, including amountDue, amount_to_pay and user_amount_statement Returns: bill/user identifiers, tokens, provider, amount due, the chosen amount_to_pay, a payment_link to the secure card form, and any user-facing fees |
| check_payment_method | Optional: check whether the user has finished the secure form and a card is on the bill yet. Returns the card's last 4 digits and name when one is set, or a PENDING status when the form has not been completed. Use only if you need to confirm the card landed (e.g. the user asks) - it is not a required step; the normal path is analyze_bill -> user fills the form -> confirm_payment_intent. Args: check_input: the user_id and bill_id to look up |
| confirm_payment_intent | Final step: submit the bill for payment, after a card has been set. You must have confirmed the amount with the user first (amount_to_pay may be partial) and quote their confirmation in user_amount_statement - do not call this until you have asked. If analyze_bill reported a need for extra information, supply it in extra_infos or submission will fail. Use entered_account / entered_provider only to correct a mis-extracted value. Pass the user's current refresh_token (from analyze_bill or a prior confirm) - do not guess. Args: confirm_input: identifiers, the amount to pay, contact info and any extra info |
| get_new_auth_token | Get a fresh auth token when a call fails with an authorization error. Args: new_token_input: contains the user's refresh token |
| fetch_bill_status | Check the payment status of a submitted bill. Read `value` for the current status. statusEvaluatedDescription is only present when the payment was declined or failed, and then explains why - relay that reason to the user. It is omitted for every other status, so treat its presence as a decline/failure. Args: bill_status_input: the bill identifier and auth token Returns: dictionary with keys value, statusDescription, and - only for declined/failed bills - statusEvaluatedDescription explaining why the payment did not go through |
| request_bill_cancellation | Cancel a bill. Args: bill_cancel_input: the bill identifier and auth token Returns: the cancelled bill id and status, or error details |