Billplz

Billplz is a Malaysian payment gateway for bills, collections, and FPX bank transfers. Agents create and track bills, manage collections and payment methods, run V5 payment orders and auto-deduct agreements, and check receipt delivery.

Verified 31 actions Basic auth available

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

An order or membership renewal needs collecting

Agent reads the payer, the amount in the smallest currency unit, and the reference

Get FPX Banks confirms the customer's bank is online right now

Create Bill issues the bill with a callback URL and the reconciliation references

Verify X Signature checks the callback before its contents are believed

The paid bill is written to the ledger and the ops channel gets the confirmation

A person releases the supplier payout run that the collected funds are paying for

What This Integration Enables

Billplz keeps three API versions alive at the same time, and that is not legacy drift. They are three different products: bills and collections in one, ordered split rules and receipt delivery in another, and payment orders, card agreements, and auto-deduct in the third. A working Malaysian integration uses all three at once, which is why this connector keeps the version visible in the operation names rather than pretending there is a single tidy API underneath.

FlowRunner agents work the whole surface. They create bills against collections, read the real-time FPX bank list before offering a payer a choice, verify signed callbacks properly rather than trusting a redirect, set up card-on-file agreements and charge them later, and assemble outbound payment orders with the duplicate guard the vendor actually enforces. Two of the operations here are wider than they look, replacing a whole setting rather than editing one, and one moves money out of the account entirely. Those are the points where human-in-the-loop belongs.

Without FlowRunner

Bank outages found by the customer A payer picks a bank that is offline and the payment fails at their end

Redirects treated as confirmation The browser says paid, and the record is written from what the browser said

Payouts checked line by line Supplier payments are typed and reviewed by eye before a batch is released

With FlowRunner

The bank list is read first Only banks reporting as active are offered, so the payer is not sent to a closed door

Confirmation comes from the callback The signed callback is the record of truth, and it is verified before anything downstream moves

Payouts are assembled, then approved The batch is built and priced against the account limit, and a person releases it

Use Case Scenarios

A bill that survives the redirect

An order in Shopify needs collecting. The agent reads Get FPX Banks first, because the active flag on that list is live status rather than configuration and Malaysian banks go offline for maintenance regularly, then presents only banks that are up. Create Bill issues the bill with a callback URL and both reconciliation references filled in. When the customer pays, the redirect tells the workflow what the browser claims and the callback tells it what Billplz knows, so the agent runs Verify X Signature on the delivery and only then writes the settled row to Xero. Where a bill shows an unexpected state, Get Bill Transactions exposes the failed attempt that preceded the successful one, which the flattened bill record does not show.
Marketplace splits that pay the right side

A marketplace bill carries a split so the seller is paid automatically. The cut fields describe what stays in the platform's account rather than what the recipient receives, and getting that backwards pays the seller the platform's margin. The agent therefore computes the retained figure explicitly, checks that the recipient's account is verified because an unverified one has the rule refused outright, and records both sides of the split in the reconciliation sheet in Google Sheets. The seller statement that goes out later is built from the same numbers the bill was created with.
Subscriptions on a card agreement

A member signs up for recurring billing. Create Agreement returns a consent URL, and nothing can be charged until the customer visits it, enters their card, and confirms. The agent tracks that state rather than assuming it, because Auto-Deduct Bill refuses an agreement in any other status and that refusal is the single commonest failure in a scheduled billing run. Members who never completed consent get a reminder through Slack to their account manager rather than a failed charge every month.

Human-in-Loop Highlight

Create Payment Order is the operation that sends money out of the account, and Billplz gives it fewer guardrails than the collection side has. There is no name check on the destination account number, so a valid number belonging to the wrong person succeeds exactly like a correct one. The bank code is a case-sensitive SWIFT code, and a typo that stays valid routes the transfer somewhere real. The one protection that exists is the reference identifier, which must be unique within its payment order collection and which Billplz genuinely enforces, so it is the only thing standing between a retried workflow and paying a supplier twice. And where a bill callback retries several times over a schedule, a payment order callback retries once, so the notice that something went wrong is easily lost for good. The agent therefore builds the run and stops. It calls Get Payment Order Limit first, because exceeding the cap fails partway through rather than being refused up front, then posts: "Supplier payout batch for 14 September is assembled: 47 orders, RM 612,400 total, against a remaining limit of RM 750,000. Four destination accounts are new this month and have never been paid before. Reference ids are unique within the collection. Release, release without the four new accounts, or hold?" The finance approver answers. The assembly and the limit check are the agent's job. The transfer that no name check will catch is not.

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

31 actions

Bills

Create Bill Issues a bill against a collection with its amount in the smallest currency unit. A callback URL is required here, because the vendor states callbacks are the only guaranteed backend confirmation. Creating a bill activates its collection automatically.
Get Bill Reads one bill's current state, flattened to a single status. Note that the paid amount can differ from the amount on some gateways, so check it rather than assuming.
Delete Bill Removes a bill. The due date is informational and does not stop a bill being paid, so deletion is the way to actually close one.
Get Bill Transactions Lists every payment attempt against a bill, which is how a failed attempt that preceded a successful one becomes visible.

Collections

Create Collection Creates the container bills are issued against.
Get Collection Reads one collection and its configuration.
List Collections Lists collections, fifteen per page.
Activate Collection Makes a collection available to receive bills.
Deactivate Collection Stops new bills on a collection. Outstanding bills stay payable, so this is not a way to cancel what is already out.
Create Collection V4 Creates a collection in the newer shape, which is the one that supports two ordered split recipients.
Get Collection V4 Reads a collection in the newer shape, including its split rules.
List Collections V4 Lists collections in the newer shape.

Payment Methods

Get Payment Methods Reads which payment methods the account currently accepts. The read that must come before any update.
Update Payment Methods Sets the accepted methods. This is a replacement rather than a patch: omitting a method's code disables it, so sending one method turns everything else off.

Receipt Delivery

Get Receipt Delivery Status Reads whether receipts are being delivered for a collection.
Activate Receipt Delivery Turns receipt delivery on for a collection.
Deactivate Receipt Delivery Turns receipt delivery off for a collection.
Set Global Receipt Delivery Applies one collection's receipt setting to every collection on the account, despite taking a single collection id. There is no undo beyond setting each collection back individually.

Payment Orders

Create Payment Order Collection Creates the container outbound payments are grouped in.
Get Payment Order Collection Reads a payment order collection and its state.
Create Payment Order Sends money out to a bank account. There is no name check on the account number, the bank code is a case-sensitive SWIFT code, and the reference identifier's uniqueness within the collection is the vendor-enforced guard against paying twice.
Get Payment Order Reads one outbound payment and its outcome.
Get Payment Order Limit Reads how much the account may still pay out. Exceeding the cap fails partway through a batch rather than refusing it up front, so this belongs before a run rather than after a failure.

Agreements

Create Agreement Sets up a card-on-file agreement and returns the consent URL the customer must visit before anything can be charged.
Get Agreement Reads an agreement's status. Checking this before a charge avoids the commonest failure in a scheduled billing run.
Revoke Agreement Cancels a card-on-file agreement so it can no longer be charged.
Auto-Deduct Bill Charges an authorized agreement. It refuses an agreement in any other status, which is why the status read belongs first.

Reference

Get FPX Banks Lists the banks with a live active flag rather than a configuration one. Malaysian banks go offline for maintenance regularly, and offering a payer a bank that is down produces a failed payment.
Get Payment Gateways Lists the gateways available to the account.

Account

Get Webhook Rank Reads the account's callback priority. Billplz degrades the rank for every failed callback attempt, and a lower rank means callbacks are scheduled at lower priority, so slow deliveries today are often damage done weeks ago. Worth alerting on.

Security

Verify X Signature Verifies a callback delivery against the signature key, handling the vendor's sorting and joining rules and dropping the signature field itself, which breaks verification if left in. The step that separates what the browser claims from what Billplz knows.

Frequently Asked Questions

What can FlowRunner do with Billplz?

FlowRunner agents can run Create Bill, Get Bill, and Delete Bill in Billplz, plus 28 more actions.

Does connecting Billplz to FlowRunner require OAuth?

No. Billplz connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can Billplz trigger a FlowRunner workflow automatically?

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

Start building with Billplz

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us