GP webpay
PaymentsGP 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.
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 is the default at that kind of door.
Without FlowRunner
With FlowRunner
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 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 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 Capabilities
25 actionsService
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.
Start building with GP webpay
Free plan, no card required. Connect in minutes.