--- title: "Pagar.me Integration" description: "Pagar.me is a Brazilian payment gateway from Stone covering cards, Pix, and boleto. Agents create customers, orders, and charges, tokenize cards, run plans and subscriptions, manage marketplace recipients and transfers, and reconcile receivables and settlements." url: https://flowrunner.ai/integrations/pagar-me date_modified: 2026-09-04T14:51:36-07:00 --- # Pagar.me [Payments](https://flowrunner.ai/integrations/category/finance-accounting) Pagar.me is a Brazilian payment gateway from Stone covering cards, Pix, and boleto. Agents create customers, orders, and charges, tokenize cards, run plans and subscriptions, manage marketplace recipients and transfers, and reconcile receivables and settlements. 124 actions · Basic auth · available [Pagar.me website](https://pagar.me/) · [Platform Documentation](https://docs.pagar.me/) · Capability data verified 2026-08-25 1. A cash forecast shows a shortfall before the next settlement date 2. Agent reads the receivables due with List Payables and the balance with Get Recipient Balance 3. Get Anticipation Limits reports the most and least that may be advanced for that date 4. Simulate Anticipation returns the actual cost of pulling the money forward 5. The nearest and furthest timeframes are priced and assembled side by side 6. The forecast, the limits, and both simulated fees post to the treasury channel 7. The finance owner decides whether to sell receivables, and on which timeframe ## What This Integration Enables Pagar.me is a Brazilian gateway from Stone, and its API is shaped like a marketplace ledger rather than a checkout. Cards, Pix, and boleto are all present, but the operations that carry the weight sit further down. Recipients go through identity verification before they can be paid, and split rules divide a sale between sellers at the moment it happens. Receivables are listed one row per installment, alongside receivable units as the Brazilian central bank defines them and settlements that match your actual bank statement. Underneath all of it sits anticipation, the machinery for turning future income into present cash at a fee. That is a lot of ledger for an agent to work with, and it is why this connector rewards automation more than a simpler gateway would. FlowRunner agents onboard sellers and watch them through verification, take payments through orders or standalone charges, run plans and usage-based subscriptions, reconcile payables against settlements, and recover missed webhook deliveries. The operations that spend money or claw it back from someone who has already withdrawn it are where the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate belongs. ### Without FlowRunner **Receivables tracked in a spreadsheet**: Future card income is estimated by hand from sales rather than read from the ledger **Advances priced by phone**: Someone asks what an advance would cost and waits for an answer before deciding **Marketplace sellers onboarded manually**: Each seller's registration and verification is chased through email until they can be paid ### With FlowRunner **Receivables read at the installment**: Every installment of every sale is listed with its settlement date and the fee taken out **Advances priced before they happen**: The limits and the simulated cost are read first, so the decision is made against a number **Sellers onboarded by a flow**: The recipient is created, the verification link is sent, and the status is watched to approval ## Use Case Scenarios ### Marketplace onboarding that ends in a payable seller A new seller signs up. The agent calls Create Recipient with their registration details, transfer settings, and anticipation settings in one request rather than three, then generates the identity verification link with Create Recipient KYC Link and sends it to them over [WhatsApp](https://flowrunner.ai/integrations/whatsapp). It watches Get Recipient until the status leaves registration, because a seller who has not completed verification cannot receive a split however many sales they make. Once approved, Update Transfer Settings sets their payout schedule, and the agent knows to check the interval and day pairing, since a weekday number sent with a monthly interval is accepted and pays on the wrong day. ### Usage-based billing that closes its own cycle A metered plan bills on consumption. Manual billing is switched on for the subscription, which means nothing is invoiced until a flow asks for it. Each period the agent records consumption with Create Usage against the subscription item, reads List Usages to check what the next invoice will bill, calls Renew Cycle to close the period, and then Create Invoice to generate and charge it. List Cycles filtered to unbilled is the safety net, because manual billing is a silent revenue leak if a cycle is ever skipped. The resulting invoices post to [Xero](https://flowrunner.ai/integrations/xero) and the arrears queue is List Invoices filtered to pending with a due date in the past. ### Reconciliation and webhook recovery Every day the agent reads List Payables for the period, filtering by waiting funds for money still to come and by paid for money already settled, and it supplies a created-since date because the vendor otherwise defaults to the last six months. Those rows are matched against List Settlements, which is the layer that lines up with the bank statement, and against List Balance Operations for the fees and transfer costs in between. If any events were missed while the listener was down, List Webhook Deliveries filtered to failed finds them and Resend Webhook replays them, so a gap heals itself rather than becoming a manual reconciliation. ## Human-in-Loop Highlight Create Anticipation is the operation on this connector that spends money rather than moves it. It advances a recipient's receivables so cash arrives earlier, and the fee depends on how far forward the money is pulled, which means the same requested amount costs different things on different dates. The timeframe parameter makes that explicit: pulling the receivables closest to settling is cheapest, pulling the furthest away is dearest, and the API will not choose for you. Cancel Anticipation works only while the request is still pending, so once Pagar.me confirms it the money has moved and the fee is spent. So the agent prepares the decision instead of making it. It reads Get Anticipation Limits, runs Simulate Anticipation on both timeframes, and posts: "Forecast is 84,000 BRL short on the 12th. Advancing 90,000 from the nearest receivables costs 1,410 in fees; from the furthest it costs 3,880. Advance, and on which timeframe?" The finance owner answers. The agent never sells receivables on its own judgment of a cash gap. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 124 actions ### Customers and Addresses 9 - **Create Customer** Creates a customer, the record a card, an address, an order, or a subscription hangs off. Send your own system's identifier as the code, since it is the only field that lets you find this customer again without storing the platform identifier. - **List Customers** Lists customers, filtered by name, email, document, gender, or your own code. - **Get Customer** Reads one customer in full, including their default address and phones. The delinquent flag is worth branching on, since it means this customer has an unpaid charge somewhere. - **Update Customer** Updates a customer's details. The vendor names the phone field differently on this route than on creation, and each is sent as documented. - **Create Address** Adds an address to a customer. The country and state are ISO codes rather than names. - **List Addresses** Lists the addresses saved on one customer. - **Get Address** Reads one address saved on a customer. - **Update Address** Updates an address on a customer. Only the second address line and the metadata may be changed here, since the street, city, state, and postal code are fixed once created, so a genuine move means creating a new address. - **Delete Address** Removes an address from a customer. An address referenced as a card's billing address should not be deleted, since the card then has none. ### Cards and Tokens 7 - **Create Card** Saves a card in a customer's wallet so later charges and subscriptions can name it by identifier. Send a token instead of the card details when the number was captured by the transparent checkout, which keeps raw card data out of your flows. Verifying the card at save time runs a zero-value authorization and catches a dead card before the first renewal. - **List Cards** Lists the cards in a customer's wallet. Only the first six and last four digits come back, which is enough to show the customer which card is on file. - **Get Card** Reads one saved card, with its brand, masked digits, expiry, status, and billing address. - **Update Card** Updates a saved card's holder details, expiry, or billing address. The card number cannot be changed, and both expiry fields are required on every update. - **Delete Card** Removes a card from a customer's wallet. A subscription still pointing at this card will fail at its next renewal, so move it first. - **Renew Card** Asks the card updater service to fetch the card's current number and expiry from the issuer, which is how a subscription survives a reissued card without asking the customer for the new one. Run it on a renewal that failed for an expired card before giving up. - **Create Card Token** Turns raw card details into a short-lived token that can be used in place of the number. This is the one route authenticated with the public key, designed to be called from a browser, and the token expires about a minute after it is issued. ### Orders and Charges 20 - **Create Order** Creates an order, the platform's top-level object, holding the items, the customer, and one or more payments. This is the operation that takes money, and a single order can be paid by several methods. A payment entry may carry a split array, which is how a marketplace divides the money at the moment of the sale. - **List Orders** Lists orders, filtered by status, customer, your own code, or a creation date range. - **Get Order** Reads one order with its items, its customer, and every charge raised against it, which is where the payment outcome actually lives. - **Close Order** Closes an open order so no further charges or items can be added, and stamps its final status. The status is required and it is a decision rather than an observation: marking an order paid whose charges never settled records it as paid anyway. - **Create Order Item** Adds a line item to an open order. The amount is in centavos, and a code is required for split transactions. - **Get Order Item** Reads one line item from an order. - **Update Order Item** Updates a line item on an open order. The amount, description, and quantity are all required, and a closed order refuses this. - **Delete Order Item** Removes one line item from an open order. - **Delete All Order Items** Removes every line item from an open order in one call. There is no confirmation and no undo, and it names no item. - **Create Charge** Creates a charge on its own without first creating an order, the shorter path when you are billing an amount rather than selling a basket. Its contract differs from the add-to-order route it shares a path with, since this one takes a customer and no order. - **Add Charge To Order** Raises another charge against an open order, which is how a single order is settled in parts or by more than one method. A closed order refuses it. - **List Charges** Lists charges, filtered by status, payment method, customer, order, your own code, or a creation date range. Overpaid and underpaid statuses mean a boleto or Pix arrived for the wrong amount, and neither is a failure the customer will report. - **Get Charge** Reads one charge, including its last transaction, which is where the acquirer's response code, the boleto URL, or the Pix QR code actually lives. - **Cancel Charge** Cancels a charge, which means a void before it settles and a refund after, since the vendor uses one route for both. Send an amount to refund part of it. In a marketplace this pulls the split recipients' shares back too, so a recipient who has already withdrawn can end up with a negative balance. - **Capture Charge** Captures a charge that was authorized but not captured, which is what actually takes the money. Split rules may be supplied here rather than at authorization, so a marketplace that does not know the division until the goods ship can decide it at capture. An authorization expires within days and capture then fails. - **Update Charge Card** Puts a different card on a charge and retries it. The vendor allows this only when the previous attempt was not authorized, so it is the recovery path for a declined card rather than a way to move a successful charge. - **Update Charge Due Date** Moves a charge's due date, which reissues a boleto or Pix rather than merely relabeling it, so the customer needs the new one. - **Update Charge Payment Method** Switches a pending charge to a different payment method, for a customer who cannot pay the boleto and pays by card instead, without canceling and re-raising. The object matching the new method is required, and reusing the split carries the marketplace division across. - **Retry Charge** Retries a charge that failed, using the same payment details. A card declined for insufficient funds may work later, while one declined as lost, stolen, or invalid never will, so read the acquirer return code before looping. - **Confirm Cash Charge** Records that a pending charge with the cash payment method was paid in person. It moves no money: it tells the platform money already changed hands so the order can complete and the reporting is right. ### Payment Links 5 - **Create Payment Link** Creates a hosted checkout page you can send to anyone, with no integration on your side. The type decides what it produces: an order link creates a one-off order per payer, a subscription link starts a recurrence. The session caps decide how many orders the link may create at all and how many may be paid, which is what makes a link a limited offer. - **List Payment Links** Lists payment links, filtered by name, status, or a creation date range. - **Get Payment Link** Reads one payment link with its URL, status, cart and payment settings, and how many sessions it has used. - **Activate Payment Link** Switches on a payment link that was created in a building state, so it starts accepting payments. The vendor answers with no body, so read the link back to confirm. - **Cancel Payment Link** Cancels a payment link so it stops accepting payments. Orders it already created are untouched: this closes the door, it does not refund anyone. ### Plans 9 - **Create Plan** Creates a plan, the template a subscription is made from, carrying the price, the frequency, and the accepted payment methods. The billing type decides when the customer pays: at the start of each cycle, at the end, which is what usage-based billing needs, or always on a fixed day of the month. Amounts are in centavos. - **List Plans** Lists plans, filtered by name, status, or a creation date range. - **Get Plan** Reads one plan with its items, pricing scheme, interval, and accepted payment methods. - **Update Plan** Updates a plan. The name, status, currency, interval, and interval count are all required on every update, and existing subscriptions keep the terms they were created with, so this changes what new subscriptions get. - **Delete Plan** Deletes a plan. To stop selling a plan while keeping its existing subscribers billing normally, set its status inactive instead, which is the reversible move. - **Update Plan Metadata** Replaces the free key and value data stored on a plan without touching its pricing. It replaces the whole object rather than merging into it. - **Create Plan Item** Adds a line item to a plan. The cycles field is the useful one: an item charged on the first cycle only is how a setup fee is modeled inside a recurring plan. - **Update Plan Item** Updates a line item on a plan. The name and status are both required on every update. - **Delete Plan Item** Removes a line item from a plan. ### Subscriptions 19 - **Create Subscription** Subscribes a customer to an existing plan, taking the price, interval, and billing type from the plan. A card is required when the payment method is a card, and it must name either a card saved on the customer or a token. A start date postpones the first charge. - **Create Subscription Without Plan** Creates a subscription that carries its own items, interval, and pricing rather than inheriting them from a plan, which is the right shape when every customer's recurrence is negotiated separately. A setup object creates a one-off order the moment the subscription starts, which is how a joining fee is charged. - **List Subscriptions** Lists subscriptions, filtered by status, customer, plan, card, billing type, your own code, a creation date range, or a next billing date range. That last pair answers what is going to be charged this week, which is the basis of a pre-billing reminder. - **Get Subscription** Reads one subscription with its items, current cycle, next billing date, card, and, where the account has marketplace splits enabled, its split rules. - **Cancel Subscription** Cancels a subscription. The option to cancel pending invoices defaults to on, so canceling also voids invoices and charges already raised but unpaid, including money the customer genuinely owes for a cycle already delivered. Switch it off to cancel the recurrence while keeping the debt. - **Update Subscription Card** Points a subscription at a different card, which is the fix for a customer whose card was reissued or declined. Send either a card already in their wallet or the new details. - **Update Subscription Billing Date** Moves a subscription's next billing date, which is how a goodwill extension or a proration is granted without canceling anything. - **Update Subscription Start Date** Moves a subscription's start date, which applies only while it has not started yet. - **Update Subscription Payment Method** Switches a subscription to a different payment method, card to boleto or a customer moving off a dead card. Moving to a card requires a card, an identifier, or a token. - **Update Subscription Minimum Price** Sets the floor for a subscription's invoice, in centavos, so a usage-based subscription that generated less than this is billed this instead. - **Update Subscription Metadata** Replaces the free key and value data stored on a subscription. It replaces the whole object rather than merging into it. - **Update Subscription Gateway Affiliation** Points a subscription at a different gateway affiliation, which matters only for an account holding several acquirer contracts. - **Update Subscription Split** Turns marketplace splitting on or off for a subscription, or replaces its division rules. The enabled flag and the rules are independent, so splitting can be switched off without losing the rules. - **Enable Manual Billing** Stops the platform generating invoices for a subscription automatically. After this the customer is not billed until a flow generates an invoice for each cycle, which is what usage-based billing needs and a silent revenue leak if it is switched on and forgotten. - **Disable Manual Billing** Puts a subscription back on automatic invoicing, so the platform generates each cycle's invoice again. - **Create Subscription Item** Adds a line item to a subscription, which is how a seat, an add-on, or a metered product is attached to an existing recurrence without changing the plan. A quantity is required when the pricing scheme is per unit. - **List Subscription Items** Lists the line items on a subscription, filtered by status, name, description, or a creation date range. - **Update Subscription Item** Updates a line item on a subscription, which is what a seat count changing mid-contract needs. A quantity is required on every update. - **Delete Subscription Item** Removes a line item from a subscription, so it stops appearing on future invoices. ### Usage, Discounts, and Cycles 14 - **Create Usage** Records consumption against a subscription item, which is what a metered plan bills from. The item's pricing scheme turns the accumulated usage into the next invoice, and a postpaid billing type is what lets the cycle close before it is priced. - **List Usages** Lists the usage recorded against a subscription item, which is how you check what the next invoice will bill before it is generated. - **Delete Usage** Removes a usage record from a subscription item, the correction for something logged twice or logged wrongly. Only worth doing before the cycle is invoiced. - **Create Discount** Adds a discount to a subscription. The cycles field is what makes a promotion end by itself, and naming an item discounts that line only. A flat discount takes centavos while a percentage takes a percentage. - **List Discounts** Lists the discounts attached to a subscription, with the cycles each has left. - **Get Discount** Reads one discount attached to a subscription. - **Delete Discount** Removes a discount from a subscription, so the next cycle is billed at full price. - **Create Increment** Adds a surcharge to a subscription. It is the mirror of a discount, with the same value, type, and cycles fields, added rather than deducted, and useful for a late fee or a contracted uplift. - **List Increments** Lists the increments attached to a subscription, with the cycles each has left. - **Get Increment** Reads one increment attached to a subscription. - **Delete Increment** Removes an increment from a subscription, so the surcharge stops applying. - **Renew Cycle** Closes a subscription's current cycle and opens the next one. It always renews forward, there is no way to reopen a closed cycle, and on a manually billed subscription it is what makes the next invoice possible. - **List Cycles** Lists the billing cycles of a subscription with their dates and whether each has been billed. Filtering to unbilled finds exactly the cycles a manually billed subscription still owes an invoice for. - **Get Cycle** Reads one billing cycle of a subscription: its window, its billing date, and whether it has been invoiced. ### Invoices 5 - **Create Invoice** Generates the invoice for one cycle of a subscription and charges it. This is the other half of manual billing: with automatic invoicing off, nothing is billed until this is called for each cycle. - **List Invoices** Lists subscription invoices, filtered by status, customer, subscription, a due date range, or a creation date range. Pending with a due date in the past is the dunning queue. - **Get Invoice** Reads one subscription invoice with its lines, its cycle, and the charge raised for it. - **Cancel Invoice** Cancels a subscription invoice, which also voids the charge raised for it. It does not skip the cycle: the subscription still moves on and that cycle simply will not be collected. - **Update Invoice Metadata** Replaces the free key and value data stored on an invoice. It replaces the whole object, and it is the only part of an issued invoice the API lets you change. ### Recipients and Marketplace 15 - **Create Recipient** Creates a recipient, a seller who can receive part of the money from your sales. The registration information is filled in differently for an individual and a company, and the platform runs the details through identity verification before the recipient may be paid. Transfer and anticipation settings can be supplied here, saving two follow-up calls per seller. - **Create Recipient (Legacy Contract)** Creates a recipient using the older contract, where the seller's details are flat fields rather than a registration object. Use this only if your account was onboarded before the current contract. - **List Recipients** Lists the recipients on the account. - **Get Recipient** Reads one recipient with its registration details, bank account, transfer settings, and status. Check the status before splitting money to them, since a recipient still in registration or refused cannot be paid. - **Update Recipient** Updates a recipient's registration details. Only fields that are still empty may be edited, because anything already filled in has been through identity verification and is frozen. - **Update Recipient (Legacy Contract)** Updates a recipient using the older contract's flat fields. The entity type is required here even when unchanged. - **Update Recipient Code** Changes the external reference on a recipient, your own identifier for the seller. - **Update Recipient Bank Account** Replaces the bank account a recipient is paid into. The new account's holder document must match the recipient's own, since the platform will not pay a seller into somebody else's account. - **Get Recipient Balance** Reads a recipient's balance, split into what is available now and what is still waiting to settle. Check it before a withdrawal, since waiting funds are not spendable however large they look. - **Update Transfer Settings** Sets a recipient's automatic payout schedule. The transfer day depends on the interval and the ranges do not overlap, so a weekday number sent with a monthly interval is accepted and pays on the wrong day. All three fields are required on every call. - **Update Anticipation Settings** Sets whether a recipient's receivables are advanced automatically, and on what terms. The type decides the model and the volume percentage caps how much of the eligible money is advanced. Anticipation costs the recipient a fee, so this is a standing instruction to pay it. - **Create Recipient KYC Link** Generates the identity verification link and QR code a recipient uses to complete proof of life. Until the seller finishes this, their status stays in registration and they cannot be paid. - **Create Withdrawal** Pays a recipient's available balance out to their registered bank account, on demand rather than on the automatic schedule. The amount is in centavos and cannot exceed the available balance. - **List Withdrawals** Lists the withdrawals made for a recipient, filtered by status or a creation date range. - **Get Withdrawal** Reads one withdrawal made for a recipient, with its status and target bank account. ### Receivables and Anticipation 13 - **Simulate Anticipation** Works out what advancing a recipient's receivables would actually cost and pay, before committing to it. The fee depends on how far forward the money is being pulled, so the same requested amount costs different things on different dates. The timeframe decides which receivables are taken: the nearest are cheapest and the furthest are dearest. - **Get Anticipation Limits** Reads the most and least a recipient may anticipate for a given payment date. Ask this before simulating, since a requested amount outside these limits is refused. - **Create Anticipation** Advances a recipient's receivables so the money arrives earlier, for a fee. This spends money, so run the simulation first and read the fee. An automatic transfer option sends the advanced amount straight to the recipient's bank account. - **List Anticipations** Lists the anticipations requested for a recipient, with the fee each cost. - **Cancel Anticipation** Cancels an anticipation that is still pending. Once the platform has confirmed it, the money has moved and the fee is spent. - **List Payables** Lists your receivables, one row per installment of every sale, with the date it becomes available and the fee taken out. This is the reconciliation source and the receivables forecast in one. With no created-since date the vendor defaults to the last six months rather than everything. - **Get Payable** Reads one receivable: its amount, the fee taken, its settlement date, and the charge it came from. - **List Balance Operations** Lists the movements in your balance, every credit, fee, transfer, and anticipation cost, in order. The status defaults to available, so ask for waiting funds explicitly to see money that has not settled. - **Get Balance Operation** Reads one movement in your balance, with the resulting running balance and what caused it. - **List Receivable Units** Reads a recipient's receivable units over a date window, the Brazilian central bank's own unit of a merchant's future card income, which is what a bank looks at when it lends against receivables or registers a lien. - **List Settlements** Lists settlements, the actual bank payments made under a liquidation arrangement, which is the layer beneath receivables and the one that matches your bank statement. - **List Recipient Settlements** Lists the settlements made to one recipient over a date window, newest first. - **Get Settlement** Reads one settlement: the amount paid, the date, and the arrangement it fell under. ### Transfers 5 - **Create Transfer** Moves money from your balance to a registered bank account. Send an idempotency key, since a retried transfer that goes through twice pays somebody twice. The amount is in centavos, and naming a recipient takes the money from that recipient's balance rather than yours. - **List Transfers** Lists transfers, filtered by status, recipient, bank account, amount, or date. This route pages by cursor rather than page number. - **Get Transfer** Reads one transfer with its status, amount, and destination account. - **Cancel Transfer** Cancels a transfer. Only one still pending: once it has been sent to the bank there is nothing to cancel, so check the status first rather than treating the failure as an error to retry. - **Get Transfer Receipt** Fetches the bank receipt for a completed transfer, which is what a seller asks for as proof of payment. Only available once the transfer has actually been transferred. ### Webhook Recovery 3 - **List Webhook Deliveries** Lists the webhook deliveries attempted, filtered by status, event name, or a creation date range. These are delivery records rather than subscriptions, since the API publishes no route for creating or removing an endpoint. Filtering by failed is how a flow finds events your endpoint missed. - **Get Webhook Delivery** Reads one webhook delivery, including the payload that was sent and how your endpoint answered, which is where you find out why a delivery failed. - **Resend Webhook** Asks the platform to send a webhook delivery again, the recovery for an event your endpoint missed while it was down. Paired with the failed deliveries list, a flow can heal a gap without anyone reconciling by hand. ## Frequently Asked Questions ### What can FlowRunner do with Pagar.me? FlowRunner agents can run Create Customer, List Customers, and Get Customer in Pagar.me, plus 121 more actions. ### Does connecting Pagar.me to FlowRunner require OAuth? No. Pagar.me connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can Pagar.me trigger a FlowRunner workflow automatically? Pagar.me doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Pagar.me?** This integration exposes Pagar.me to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/pagar-me. Site index: https://flowrunner.ai/llms.txt