--- title: "GP webpay Integration" description: "GP webpay is the Global Payments Europe card gateway used across Czechia, Slovakia, and central Europe. Agents check payment status and detail, capture, reverse, and refund, close batches, charge recurring and card-on-file subscriptions, and manage tokens and PUSH payment links." url: https://flowrunner.ai/integrations/webpay date_modified: 2026-09-04T14:51:36-07:00 --- # GP webpay [Payments](https://flowrunner.ai/integrations/category/finance-accounting) GP webpay is the Global Payments Europe card gateway used across Czechia, Slovakia, and central Europe. Agents check payment status and detail, capture, reverse, and refund, close batches, charge recurring and card-on-file subscriptions, and manage tokens and PUSH payment links. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 25 actions · Custom auth · available [GP webpay website](https://www.gpwebpay.cz/) · [Platform Documentation](https://gpwebpay.cz/) · Capability data verified 2026-08-25 1. The daily cut-off arrives for orders that were authorized but not yet captured 2. Agent reads what actually shipped today from the fulfillment record 3. Get Payment Detail compares each payment's authorized amount against the value that left the warehouse 4. Capture Payment takes only the shipped value, leaving partly shipped orders partly captured 5. Reverse Capture is still available on everything captured today, and stays available only until the batch closes 6. The day's captures, partial captures, and untouched authorizations are summarized for the controller 7. The controller closes the batch, which is the moment same-day corrections stop being possible ## What This Integration Enables GP webpay is the Global Payments Europe card gateway used across Czechia, Slovakia, and central Europe, and the honest description of this connector is that it is the back office of a checkout it does not own. The normal payment starts in a customer's browser, so almost every operation here acts on a payment that already exists: read its status, capture it, reverse the capture, refund it, reverse the refund, close it, and eventually settle the whole day. One route originates anything at all, the push payment link that emails a customer a way to pay, and it exists precisely because a flow has no browser to work with. That shape suits agents well, because the back office is where the repetitive judgment lives. FlowRunner agents resolve payments whose customers never came back from the gateway, capture against what actually shipped, and keep recurring charges on the right route for their type. They check a token or a master payment before charging it rather than after the decline, and revoke a link the moment an invoice is settled another way. What they do not do is decide when the day is closed, because that is the operation that removes everyone else's ability to correct anything, and [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) is the default at that kind of door. ### Without FlowRunner **Corrections found after settlement**: A wrong capture surfaces the next morning, when only a refund is left and the cardholder sees both entries **Full amount captured out of habit**: Orders are captured for what was ordered rather than what actually shipped **Every recurring charge sent the same way**: A fixed subscription, a metered charge, and a customer-initiated purchase all go out on one route ### With FlowRunner **Corrections made while they are still free**: The window between capture and batch close is used deliberately, and closing it is a decision rather than a schedule **Captured for what shipped**: Partial captures match the delivered value, so the cardholder is charged for what they received **Each charge sent as what it actually is**: Metered, fixed, and card-on-file charges use their own routes, which is a compliance question as much as a decline-rate one ## Use Case Scenarios ### The customer whose browser never came back A shopper pays and then closes the tab, or their connection drops on the way back from the gateway. Your store in [Shopify](https://flowrunner.ai/integrations/shopify) has an order with no confirmed payment. Rather than guessing, the agent calls Get Payment Status, which is the authoritative answer to whether that payment happened, and Get Payment Detail when it needs the authorized, captured, and refunded amounts alongside the authorization code. For bank-button payments where the gateway cannot determine the outcome by itself, Resolve Payment Status is how the merchant states it. The order is released or canceled on the platform's answer instead of on a browser's silence. ### An invoice link that cannot be paid twice An invoice goes out from [NetSuite](https://flowrunner.ai/integrations/netsuite) with a push payment link attached, which is the one way a flow can originate a payment here. The agent records the link and watches it. If the customer pays by bank transfer instead, the agent revokes the link immediately, because a live link and a settled invoice together are how a customer pays twice and someone spends an afternoon issuing a refund. If it expires unpaid, the status read says so and the collections sequence picks it up rather than assuming silence means refusal. Expiry itself is capped by the account settings rather than by what the request asks for, so the agent reads the status rather than trusting its own calculation. ### Recurring charges sent as the right kind of charge Before any recurring charge, the agent reads the master payment's status, because a revoked or expired master makes every subsequent charge fail and that is a decline you can avoid asking for. Then it picks the route by what the charge actually is: a fixed monthly amount, a usage-based amount on an agreed schedule, or a prepaid balance top-up. A purchase the customer is initiating right now with a stored card is a different route again, and the card schemes treat a customer-initiated purchase differently from a merchant-initiated recurring charge. When a subscription is canceled, the agent revokes the master payment, since leaving it alive means the next charge still goes out. ## Human-in-Loop Highlight Close Batch is the only operation on this connector that takes no payment number. It acts on the whole merchant, sends every capture and refund in the batch for settlement, and stops Reverse Capture and Reverse Refund working on all of them at once. Before it runs, a mis-captured order is a free correction that the cardholder never sees. After it runs, the same mistake is a refund: a visible debit and a visible credit on the customer's statement, days apart, with fees attached and a support conversation in between. So the agent captures all day and never closes the day. At cut-off it posts the summary: "41 captures totaling 284,110 CZK, 6 of them partial against short shipments, 3 authorizations left uncaptured because nothing shipped, 2 refunds raised this morning. All 41 captures and both refunds are still reversible until the batch closes. Close?" The controller can reverse the two that look wrong first, then close. Nothing about that decision is mechanical: it depends on whether the warehouse count is trusted yet, on whether a known short shipment is about to be corrected, and on whether anyone is still working. The agent has done the arithmetic. The person decides that today is finished. 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 25 actions ### Service 1 - **Echo** Checks the interface is up. The vendor is emphatic that this is the only method that may be used for availability checks, and polling any other one risks having your access limited. ### Payments 11 - **Get Payment Status** Returns a payment's state without its details. The authoritative answer to whether a payment happened when a customer's browser never came back. - **Get Payment Detail** Returns a payment in full: masked card number, brand, the authorized, captured, and refunded amounts, the authorization code, and timestamps. - **Resolve Payment Status** Finalizes the status of a bank-button payment where the gateway cannot determine the outcome by itself and the merchant has to state it. - **Reverse Authorization** Releases funds blocked on the cardholder's account without taking them. The window for this is limited, and past it the only route is capture followed by refund, which the cardholder sees. - **Capture Payment** Takes blocked funds from the cardholder. This is what moves money on a payment authorized without immediate capture, and it is how you charge only what you actually shipped. - **Reverse Capture** Cancels a capture, but only until the batch closes. After that the money has left and a refund is the only route. - **Refund Payment** Returns funds to the cardholder in full or in part. - **Reverse Refund** Cancels a refund that has not yet settled, which again holds only until the batch closes. - **Close Payment** Closes a payment to all further operations. Afterwards no capture, refund, or reversal is possible against it, and a payment left open closes by itself eventually. - **Delete Payment** Marks a payment deleted so it stops appearing in searches. It is a hide rather than an erase, and the vendor keeps the record, which is what an audit needs. - **Close Batch** Closes the current batch and sends its captures and refunds for settlement. It takes no payment number and acts on the whole merchant, which is why this page's human gate sits here. ### Recurring 5 - **Get Master Payment Status** Returns the state of the original cardholder-authorized payment that later recurring charges are taken against. A revoked or expired master makes every subsequent charge fail. - **Revoke Master Payment** Invalidates a master payment so no further recurring charge can be taken. This is what a canceled subscription should call, because leaving it alive means the next charge still goes out. - **Charge Usage-Based Subscription** Takes a recurring charge whose amount varies with usage. The card schemes treat a variable amount on an agreed schedule differently from a fixed one, and the wrong route raises declines. - **Charge Regular Subscription** Takes a fixed-amount recurring charge on an agreed schedule. - **Charge Prepaid Top-Up** Takes a top-up charge against an existing master payment, for the account-balance model where a customer refills rather than being billed for a period. ### Tokens 5 - **Get Token Status** Reports whether a stored card token can still be charged, which turns an avoidable decline into a check. - **Revoke Token** Invalidates a stored card token. It is irreversible and the customer has to enter the card again, which is what a remove-saved-card button should call. - **Get Card Data** Returns what the gateway holds about a tokenized card: masked number, brand, and expiry. The safe way to show a customer which card is on file without holding a number yourself. - **Charge Card On File** Charges a registered card for a purchase the customer is initiating now. The schemes distinguish this from a merchant-initiated recurring charge, and sending the wrong kind is a compliance problem as well as a decline risk. - **Charge Usage-Based Token Payment** Takes a merchant-initiated, usage-based charge against an established master payment and token. ### Payment Links 3 - **Create Payment Link** Creates a push payment link and emails it to the customer. This is the one way to originate a payment from a flow, since everything else here acts on a payment that already exists. - **Get Payment Link Status** Reports whether a link has been used, is still waiting, or has expired. - **Revoke Payment Link** Invalidates a link so it can no longer be paid, which is what an invoice settled another way calls for before the customer pays twice. ## Frequently Asked Questions ### What can FlowRunner do with GP webpay? FlowRunner agents can run Echo, Get Payment Status, and Get Payment Detail in GP webpay, plus 22 more actions. ### Does connecting GP webpay to FlowRunner require OAuth? GP webpay uses a custom authentication method to connect to FlowRunner. ### Can GP webpay trigger a FlowRunner workflow automatically? GP webpay doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at GP webpay?** This integration exposes GP webpay 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/webpay. Site index: https://flowrunner.ai/llms.txt