Take payments tied to your workflow

Audience: power users (Pay-as-you-go and up) · Recipe: Take payments tied to your workflow, with the record advancing itself when the money clears.

What you'll build

A record that reaches an awaiting-payment state produces a pay link automatically. Your customer clicks it, lands on the connected processor's hosted checkout page, and pays. When the payment clears, FastYoke advances the record to Paid on its own and pushes the change to every open screen in real time. No one on your team keys in a status.

The processor is the processor. FastYoke never touches a card number and is not a money transmitter — the payment provider you connect (the Vendara connector) authorizes, captures, and settles the funds. FastYoke's job is to mint the pay link at the right moment in your workflow and to move the record forward the instant the provider confirms the money arrived.

Before you start

• A workflow (an FSM) with a state that means "we're waiting on money" — call it Checkout or Awaiting payment — and a Paid state, with a transition connecting them. If you don't have one, build the two states and the edge between them in the FSM Designer first.
• A record that carries an amount due in one of the flows the connector supports — for example a service visit or a point-of-sale transaction.
• A Pay-as-you-go plan or higher. The payment connector is a paid-tier feature.
• A payment-provider account for the connector FastYoke supports (Vendara). You'll paste API credentials — an API key and a merchant identifier — so have them handy, but don't paste anything yet; the connect screen encrypts them at rest.

Steps

1. Connect your payment processor

Open the integrations area and find the payment connector listing. Choose Connect and paste your provider credentials — typically an API key and a merchant identifier. FastYoke encrypts both immediately; the plaintext is written once to the encrypted store and never read back into a response. The connection is one row per tenant and fully tenant-scoped, so nothing you connect here is ever visible to another tenant on the platform.

Give the connection a label you'll recognize ("Acme Live", "Acme Test") and save. The connector reports back a status; a green active means FastYoke can create invoices and read their payment status on your behalf.

2. Mint the pay link when a record enters "awaiting payment"

Wire the pay link to the state, not to a button someone has to remember to press. When a record transitions into your Checkout / Awaiting-payment state, the connector creates an invoice for that record's amount due and stores the returned payment URL on the record. That URL is the checkout link — the one you put in a "Pay now" email, a customer-portal button, or an SMS.

Because the invoice is created on the transition into the state, you never generate a stale link. Move an order to Awaiting payment and the pay link is there; the amount on the checkout page is the record's live total, not a value someone copied by hand.

3. Let payment move the record forward

You do not poll the provider yourself, and you do not ask your customer to report back. A background pass runs on the FastYoke worker: for every record parked in Checkout, it refreshes the invoice's payment status from the provider and reads the remaining balance. The terminal signal is the balance, not a free-text label — once the remaining balance hits zero, the invoice is paid, full stop.

When a record settles, FastYoke fires the Checkout → Paid transition through the normal FSM engine. That means the same guard evaluation, the same append to the event log, and the same WebSocket broadcast any other transition gets — so a dashboard open across the office flips to Paid the moment the money lands. The writeback is idempotent: a record that's already Paid fires no second transition, so a late poll or a duplicate provider event can't double-advance it.

4. Test the round trip

Connect a test/sandbox account in step 1, push a record into Checkout, and open the pay link. Confirm the checkout page shows the right amount. Pay it with a provider test card, then watch the record: within one polling pass it should transition to Paid on its own, and the event log should carry the transition with its timestamp. The event-log row is your durable, append-only proof that the money moved and when — it is never updated or deleted.

Take it further

• Guard the transition. Put a JSONLogic guard on the Checkout → Paid edge if some records need more than money to advance — a signed document on file, an inventory check, a manager sign-off. Payment becomes one precondition among several rather than an automatic gate.
• Record it in the ledger. If you run the accounting features, post the captured payment to a revenue and cash account so a paid record shows up in your books without a second entry.
• Scale across tenants. On the reseller and white-label plans, each tenant you run connects its own payment provider, so every one of your customers collects money into their own account, not yours — each connection is one row, fully tenant-scoped.
• Fan out on the state change. Fire an outbound webhook on Checkout → Paid to notify a fulfillment system, or push the paid order into your accounting connector, so "money arrived" ripples out to everything downstream.

Related

• Fire a webhook when a record changes state
• Connect QuickBooks: push records on a transition
• Bill your own customers
• Integrations documentation