FlowRunner
PricingContact
Theme
Start Free

Pagar.me

Payments

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 Platform Documentation Capability data verified 2026-08-25
A cash forecast shows a shortfall before the next settlement date
Agent reads the receivables due with List Payables and the balance with Get Recipient Balance
Get Anticipation Limits reports the most and least that may be advanced for that date
Simulate Anticipation returns the actual cost of pulling the money forward
The nearest and furthest timeframes are priced and assembled side by side
The forecast, the limits, and both simulated fees post to the treasury channel
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 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. 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 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.

Start building with Pagar.me

Free plan, no card required. Connect in minutes.