GoPay

GoPay is a Czech payment gateway for cards, bank transfers, and wallets. Agents create standard, pre-authorized, and recurring payments, capture and refund, charge recurrences on demand, pull account statements and EET receipts, and check payment status.

Verified 16 actions OAuth available

GoPay website Platform Documentation Capability data verified 2026-08-25

A customer asks to return part of an order that was registered for Czech sales reporting

Agent reads the original payment and its line items with Get Payment

Get Payment EET Receipts confirms the sale was registered and returns its FIK and BKP codes

Agent assembles the refund amount in cents and the item breakdown the vendor requires

The proposed correction is staged against the payment record with its original codes

The breakdown and the existing receipt codes post to the finance channel

The finance owner confirms the lines, and Refund Payment re-registers the corrected sale

What This Integration Enables

GoPay is a Czech gateway, and the thing that separates it from a generic card processor is that a payment here can carry a legal obligation. A sale registered under Czech electronic sales reporting has receipts with FIK, BKP, and PKP codes attached to it, and a refund does not simply reverse money. It re-registers the sale. That makes GoPay a connector where the accounting consequence of a write matters as much as the payment.

FlowRunner agents create standard, pre-authorized, recurring, and identification payments through a single route, capture or release pre-authorized funds, charge on demand against a card the customer already authorized, and read the platform's own answer on payment state rather than trusting a callback. On the reporting side they pull account statements as files, read the sales registration receipts for a payment, and list receipts for a workshop across a date range. The connectors do the mechanical work. The judgment about what gets filed stays with a person.

Without FlowRunner

Tax receipts tracked separately Sales registration lives in one system and the payment record in another, and they drift

Partial refunds done by hand Someone recalculates the line breakdown in a spreadsheet before touching the gateway

Statements pulled monthly Account statements are downloaded by a person and reconciled days after the money moved

With FlowRunner

Receipt state on the payment Registration codes are read back against the payment they belong to, on every refund

Breakdown assembled by an agent The item lines and amounts are built from the original payment, then confirmed by a person

Statements pulled on a schedule The statement file is fetched, decoded, and matched against payments without anyone exporting

Use Case Scenarios

One route, four kinds of payment

The agent decides what shape of payment a situation needs and fills the matching fields on Create Payment. A straightforward sale leaves the extras empty. A booking that should hold funds without taking them sets pre-authorization, and a later Capture Pre-Authorized Payment takes the exact sum once the service is delivered, releasing the rest back to the card. A subscription sets a recurrence cycle, and Create Recurrence charges the next installment on demand with no customer interaction. Before building a checkout, List Payment Methods reports what is actually enabled on that point of sale for that currency, so the options offered match the account rather than a hard-coded list.
Callbacks treated as signals, not as data

GoPay's notification tells you that a payment changed. It does not tell you what it changed to. So the agent's first move on any notification is Get Payment, and the state it reads there is what drives everything downstream: an order released for fulfillment in Shopify, a line written to Xero, a summary posted to Slack. A pre-authorization that nobody captures lapses in four days, so a parallel sweep reads pending authorizations and warns the operations owner before the block expires and the money was never yours.
Reconciliation from the statement file

On a schedule, the agent calls Get Account Statement for the previous period. The response is a binary file rather than a JSON payload, encoded with its format so a later step can decode it, and it may arrive as CSV, XLS, or the Czech ABO format. The agent parses the rows, matches each movement against payments read with Get Payment, and appends the reconciled set to a sheet in Google Sheets. Anything it cannot match becomes an exception with the statement row and the candidate payments attached, so the controller reviews a short list instead of a full ledger.

Human-in-Loop Highlight

A refund on this connector is not only a movement of money. For a payment registered under Czech sales reporting, the vendor requires the item lines and the registration block on the refund call, and it re-registers the sale with the corrected figures. Get Payment EET Receipts will then show that correction with its FIK and BKP codes, and those codes are a record you do not get to edit afterward. So the agent stops before Refund Payment on any registered sale. It posts the original receipt codes, the lines it proposes to return, the recalculated total in cents, and asks: "Refunding two of the four lines on payment 3049881, 1,240 CZK of 3,900 CZK. This re-registers the sale. Are these the correct lines?" The finance owner confirms or corrects the breakdown, and only then does the correction reach the register.

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

16 actions

Payments

Create Payment Creates a payment and returns the gateway URL to send the customer to. One route covers four kinds: leave the extras empty for a standard payment, set pre-authorization for a pre-authorized one, set a recurrence cycle for a recurring one, or set the verification PIN for an identification payment.
Get Payment Reads a payment's current state. This is what a notification callback should trigger, because GoPay's notification says the payment changed rather than what it changed to.
Refund Payment Refunds a paid payment in full or in part, with the amount named in cents. For a payment registered under Czech sales reporting, the item lines and the registration block must be supplied as well, and the vendor re-registers the sale.
Capture Pre-Authorized Payment Charges funds blocked by a pre-authorized payment. Leave the amount empty to take the full blocked sum, or give an amount and item lines to take part of it and release the rest back to the card.
Void Pre-Authorization Releases blocked funds back to the customer's card. A pre-authorization holds for four days, after which the block lapses on its own and the money was never collected.
Create Recurrence Charges the next installment of an on-demand recurring payment against the card the customer already authorized. No customer interaction is needed, and the flow chooses when and how much.
Void Recurrence Cancels a recurring payment so no further installments are taken. The vendor's own advice is to attempt collection at least three times first, since a single failure is usually transient.
List Payment Methods Lists the payment methods and bank groups actually enabled on a point of sale for one currency. Used to build a checkout from what the account supports rather than from a hard-coded list.

Statements and Sales Reporting

Get Account Statement Generates an account statement for a date range and returns the file. The response is binary rather than JSON and may be CSV, XLS, or the Czech ABO format, so it comes back encoded with its format for a later step to save or parse.
Get Payment EET Receipts Returns the Czech sales-registration receipts recorded for one payment, with their delivery state and their FIK, BKP, and PKP codes.
List EET Receipts Lists sales-registration receipts for a virtual workshop over a date range. The vendor caps the window at thirty days, so a yearly report is built from twelve calls.

Accounts and Wallets

Get Wallet Info Reads a personal GoPay account and its electronic-money account balances. This is a PSD2 service and needs the account information scope plus the account owner's consent, not merely merchant credentials.
Get Merchant Info Reads a merchant account, its address, and its electronic-money account balances. Also a PSD2 service, and the identifier it takes is the EVC rather than the GoID.
List Account Movements Lists the movements on an electronic-money account over a date range. Pages here are numbered from zero and capped at twenty five rows, unlike the rest of the API.
Create Wallet Payment Initiates a payment from one electronic-money account to another with its owner's consent. Nothing moves until Confirm Wallet Payment is called.
Confirm Wallet Payment Executes a created wallet payment. Read the answer carefully: a paid state means it finished, while a payment-method-chosen state with a gateway URL means the account owner still has to authorize it in a browser and the money has not moved.

Frequently Asked Questions

What can FlowRunner do with GoPay?

FlowRunner agents can run Create Payment, Get Payment, and Refund Payment in GoPay, plus 13 more actions.

Does connecting GoPay to FlowRunner require OAuth?

Yes. GoPay connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.

Can GoPay trigger a FlowRunner workflow automatically?

GoPay doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with GoPay

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us