How MakePay works with Plutio
A Plutio workspace brings customer invoices into the same place as your client work. MakePay’s connection keeps the original workspace, customer and invoice attached to a crypto payment, with separate controls for collecting money and recording money already received.
Choose the workflows your business needs: reviewed links for eligible sent invoices, separately authorized received-payment recording, manually reviewed drafts and optional future-draft rules for one selected link. These paths require original supported fiat evidence; old crypto payments are not reconstructed from current prices.
Before you connect
- A merchant-created API client from Plutio Settings → API manager, with its client ID and secret and access enabled for the intended workspace. You do not register a separate MakePay-owned OAuth app for this merchant connection.
- The native workspace subdomain and confirmation of the returned workspace name, currency and time zone. A client can access multiple enabled workspaces; confirm the specific one this connection will use.
- For collection, an ordinary sent invoice with a current positive balance in a supported fiat currency and amount precision. Configure MakePay merchant settlement before sharing a customer link.
- For recording or source-based drafts, an eligible confirmed production MakePay payment with its original supported fiat value. A current exchange rate or editable payment-link amount cannot fill missing historical evidence.
- For a future-draft rule, an active company-owned one-time MakePay link without an existing invoice connection, an existing native Plutio customer and one quantity-one untaxed item. Review positive exact minimum and maximum amounts in the selected link’s fiat currency before authorizing the rule.
- Permission appropriate to the native invoice actions you enable. Plutio’s webhook event checkboxes do not make its REST API read-only or restrict it to invoices.
Set up Plutio with MakePay
- 01
Prepare a client for the right workspace
Create a named API client in Plutio’s API manager and enable its intended workspace. Open MakeCrypto → Bookkeeping → Integrations → Plutio, inspect the credentials, select the returned active workspace and confirm its details. MakePay stores the credentials encrypted; tokens and secrets are not shown in connection summaries.
- 02
Import first, then choose payment options
Review the imported invoices and their current native balances. Imports start enabled; collection, payment recording, draft creation and MakePay notifications start off. Enable only the workflows you intend to use, and acknowledge Plutio’s native payment/receipt behavior before enabling recording.
- 03
Approve a link for one sent invoice
Choose an eligible sent invoice and review the exact remaining fiat principal. Approve its time-limited original MakePay collection link and share that link with the client. This does not edit the Plutio invoice, send a payment-request email or create a native payment record. Changed invoice or payment evidence can stop new checkout instructions.
- 04
Choose individual or future-link recording
After a payment is confirmed and paired, review it individually before recording it against the original invoice. Alternatively, separately authorize future recording for that exact original link before it is paid. The future rule has its own consent and window; the connection setting and collection approval do not create it.
- 05
Prepare an unpaired payment as an unsent draft
For an eligible confirmed source with saved fiat evidence, explicitly select the existing Plutio customer, review one quantity-one untaxed item and any optional due date, then approve draft creation. The draft and its item are verified separately. MakePay does not request sending, emailing or finalizing the new draft. Review the completed document in Plutio.
- 06
Optionally authorize future drafts for one selected link
In Invoice rules, choose New invoice rule, select the active company-owned one-time link and an existing Plutio company or individual client, and name the single untaxed item. Enter Minimum per payment and Maximum per payment. You can add a total amount cap, invoice count cap and end date/time; leaving optional limits empty continues until paused, subject to the original link’s own expiry. Review the exact scope and separately confirm future drafts and the one-item untaxed treatment. Enabling draft creation alone authorizes no rule.
- 07
Monitor held payments and pause future drafts
Read the saved rule’s customer, amount range, caps and end time in its original connection history. Payments needing individual review retains held sources and their reasons; continue in Invoice creation or Payment history rather than assuming an invoice was created. Pause rule stops unstarted rule-authorized phases. To change its scope or limits, pause the old rule and review a new authorization.
- 08
Finish the original operation when review is needed
Use saved recovery history for the original payment, draft or item. An uncertain native payment can require explicit identification of its original receipt. If an identified draft still has an unstarted item after approval expires, review and authorize that same remaining item again. This does not replace the invoice or change its original source and value.
What happens when a customer pays
A collection match is separate from a Plutio payment
The collection link retains one original invoice, workspace and approved amount. A qualifying confirmed settlement is paired in MakePay first. Native recording applies one whole eligible source amount to one same-currency invoice, within its current balance. A smaller source can pay part of an invoice, but this workflow does not divide one payment across several invoices. An original Plutio checkout cannot be redirected to another invoice.
Future recording follows one explicit original link
The optional rule applies only to its original source and saved fiat contract. Payment must qualify after authorization and within the original link deadline; processing can finish later. Pausing blocks unstarted recording and requires fresh review before any new authorization. It does not erase received funds or stop verification of an already-dispatched original request. Enabling a setting today does not authorize an older payment.
A reviewed draft keeps one source and one original item
Manual creation uses the confirmed source’s saved fiat principal, an explicitly chosen existing customer and a single untaxed item. It does not infer a customer from an amount or invent a past issue date. Draft creation and item attachment are separate stages on the same original document. A fresh remaining-item approval can authorize only that unchanged item on that identified draft; it cannot create a replacement. Recording the source against the completed draft is a separate approval.
Future draft rules use saved payment evidence
A rule covers only its selected link, existing customer and reviewed item. The payment’s saved first confirmation must be strictly after authorization and within any deadline. Its original fiat principal must match the approved currency and fall within the exact inclusive minimum and maximum; any total and count caps also apply. Each qualifying source creates an unsent draft with one item, quantity one, using that source’s saved fiat value. The rule does not use crypto quantity, today’s rate or a later link amount as invoice principal. It does not cover older payments or authorize recording a receipt.
Held payments remain visible instead of becoming guesses
A source or fresh review that cannot qualify is retained with its reason for individual review. Missing original fiat evidence, a changed customer or link scope, or expired authority does not authorize an improvised draft. Pause and connection changes block unstarted rule-authorized phases; original readback remains available. If a draft already exists, continue its original operation and, where needed, separately approve its same remaining item. A rule’s ongoing lifetime does not extend an individual operation’s approval.
Recovery and notifications keep their own state
A missing or uncertain native response does not authorize another financial request. Recovery verifies the original identified payment or the original draft and item. Amount similarity alone does not identify a receipt. Checkout matches, native recordings, draft completion and review problems have separate optional MakePay notices. A notification failure does not undo verified financial work or send it again.
Check these connection limits
- Public collection requires an eligible ordinary sent invoice. Native drafts, recurring or split arrangements, archived/cancelled/deleted invoices and unsupported values cannot use this checkout. An eligible draft may receive a separately reviewed payment record without becoming eligible for public collection.
- Draft creation requires either individual review or an explicit future rule for one selected eligible link. Both paths use an existing customer and one quantity-one untaxed item with matching native zero-tax and zero-discount totals. Rules do not cover arbitrary incoming wallet payments. Additional tax/template modes, new customers, attachments and native expense exports are not available in the described scope.
- A future rule needs current draft-creation authority as well as qualifying first-confirmation evidence. Leaving optional caps and end time blank does not override link expiry, changed scope or a paused rule. Payments confirmed before authorization are excluded; saving a rule is not permission to backfill them.
- Historical crypto sources without original supported fiat evidence are unavailable through these workflows. Crypto units, current rates and today’s editable link cannot substitute for the payment’s saved principal. Flexible deposits, donations and subscriptions need separately qualified handling.
- The recording API used here sends invoice identity and amount. MakePay does not choose a historical native payment date, receiving bank account, payment method or receipt-email setting through that action. Plutio controls its native receipts and independently configured behavior; delivery or suppression of receipt emails is not promised.
- Imports and recovery use bounded work. Incomplete, changing or excessive native history can require review rather than immediate collection or recording. No fixed import or payment-processing latency is promised.
Setup resources
Follow the detailed connection guide and your software’s own account requirements. Configure merchant settlement before sharing a customer invoice.
