ERPNext payment requests and online payment links

How ERPNext payment requests and online payment links work

Finance teams often send invoices on time and still wait weeks for cash, partly because the customer has to find the invoice, work out how to pay it and then tell someone the payment was made. An ERPNext Payment Request closes part of that gap by attaching a payable amount to the sales document itself. It records that an amount needs to be paid, and it does not post to the General Ledger. That distinction matters for the close: the accounting entries still come from the Sales Invoice, and the cash side comes from a payment entry that is recorded when money actually arrives. Inward requests can be created from a Sales Order or Sales Invoice and emailed to the customer with an online payment link, but only when a Payment Gateway Account is configured for the company and currency involved.

Teams usually need this when customers pay by card or a hosted gateway and the finance team wants the request traceable to the document it relates to. The same DocType can also carry offline instructions, such as bank-transfer details, for customers who pay by wire. Outward requests, used for supplier payments, follow a similar pattern but serve a different purpose. Before rollout, confirm with your gateway provider and your ERPNext version which gateways are supported as ERPNext integrations, how the link behaves for partial amounts, and which email template and sender address the customer will see. Your own environment also decides whether the payment link is reachable from the internet and how the gateway's return and webhook URLs are configured.

A payment request does not replace the accounting that follows a receipt. When the customer pays, someone still needs to create or confirm a payment entry, allocate it against the invoice and reconcile the bank transaction, typically through ERPNext bank reconciliation workflows. Plan who owns those steps, how failed or abandoned payments are followed up, and how refunds are handled, because a link that was emailed and never completed is still an open request. Treat the payment request as the customer-facing trigger and the payment entry as the accounting record, and design your month-end checks around that split.

Inward, bank-transfer and outward requests compared

An inward online link request asks a customer to pay an amount online. In ERPNext, a Payment Request can be raised from a Sales Order or Sales Invoice and emailed to the customer with an online payment link, provided a Payment Gateway Account is configured. The request records that the amount needs to be paid and does not post to the General Ledger, so the accounting effect follows the payment record, not the request itself.

Trigger: A user creates the Payment Request from a Sales Order or Sales Invoice, which carries the customer and amount into the request.
Recipient receives: An email containing an online payment link, once the gateway account is set up and linked.
Gateway dependency: Without a Payment Gateway Account, the request still records the amount due but has no online link to send.
Ledger effect: Creating and sending the request does not post to the General Ledger.
Recording the payment: Confirm in the ERPNext Payment Request documentation whether a successful gateway payment is posted back to the invoice automatically or needs a user action.

Before go-live, confirm with your payment gateway which fees, settlement timing and refund handling apply, and test one payment end to end in a non-production site.

Configuration options and when each fits

This table compares the main setup choices for ERPNext Payment Requests: gateway accounts, reference documents, email handling and sending mode. Read each row against your own billing volume, number of companies and currencies, and how much review you want before a customer receives a link. The main takeaway is that gateway scope and sending mode are the decisions that are hardest to change later.

Option	Choose it when	Trade-off	What to confirm
One gateway account per company	Each legal entity collects through its own merchant account and settles to its own bank	More gateway accounts to set up and reconcile, but payments settle to the correct entity	Which gateway accounts your provider issues per entity and currency
Gateway account per currency	You invoice customers in several currencies and your provider settles each currency separately	Each currency needs its own configured account, and the wrong one can be picked on a request	Whether your provider supports the currencies and settlement accounts you need
Single shared gateway account	One company, one currency and one settlement bank	Simplest to maintain, but it cannot separate collections by entity or currency later without rework	Whether your reporting needs entity-level payment splits
Reference to a Sales Order	Payment is due before the invoice exists, such as deposits or prepayments	The request tracks the order amount, so partial invoicing needs a clear rule for what is still owed	Your rule for deposits versus final invoice amounts
Reference to a Sales Invoice	The invoice is final and the customer should pay its outstanding amount	Clean match to the receivable, but payment timing relies on the invoice being issued first	Whether invoices are submitted before the request is sent
Manual sending from the form	Volumes are low or each request needs a human check on amount and recipient	Adds staff time per request, but errors are caught before the link leaves the company	Who has permission to create and send requests
Automated sending or scheduled follow-up	Recurring or high-volume collections follow a predictable pattern	Faster collection, but a wrong template or recipient is sent at scale	How your team tests templates and reviews recipient data before automation is enabled
Custom email template and recipient choices	Your customers expect a branded message or payments go to a finance contact rather than the sales contact	Each template needs upkeep as wording and contacts change	Which templates and contact roles you need, and who approves wording
Offline bank-transfer instructions	Some customers cannot or will not pay online, or local rules require bank transfer	No automatic matching, so payments must be reconciled by hand or through bank feeds	Which bank details appear on the request and how receipts are matched afterward

Setting up payment requests and gateway accounts

This sequence takes ERPNext from company and bank setup to a tested payment request, confirming that a customer can pay online and that the payment reconciles against the invoice. Each step ends with a check so the team knows it can move on.

Confirm company, currency and bank accounts
Before any payment request is created, the finance lead confirms the Company record, the default currency, and the bank and cash accounts that will receive money. Each receiving account should map to the correct ledger account in the chart of accounts, and the team should agree which accounts apply to online card or gateway receipts and which apply to bank transfers. Check that every account needed for incoming payments exists, is active, and belongs to the right company. You know this step is done when the finance lead can name the receiving account for each payment channel without looking it up.
Configure the payment gateway account
An administrator creates a Payment Gateway Account for each provider, selecting the gateway, linking it to the company's receiving bank or payment account, and entering the provider credentials the integration requires. Credentials should be stored by the provider settings, not in shared documents, and the test or live mode should be set deliberately. Confirm with your provider which gateway types are supported in your ERPNext version and which account configuration they expect. You know this step is done when the Payment Gateway Account saves without errors and is visible when a payment request is created against an invoice.
Set default accounts and email settings
The finance lead sets the default receivable, payment and bank accounts used when payment requests are processed, and the outgoing email account that will send payment links to customers. The email account should use a sender address the customer's finance team recognizes, with delivery tested through the mail server your organization operates. Confirm the print format and the language used in the email template, since the payment link text is sent to customers. You know this step is done when a test email sent from the configured account arrives in a mailbox you control.
Create a test payment request from a sales invoice
Using a test customer and a submitted Sales Invoice in a non-production site or with a dedicated test customer, a user opens the invoice and creates a Payment Request, selecting the Payment Gateway Account. The request records the amount to be collected and does not post to the General Ledger at this point. Confirm the amount, currency, customer contact and reference document match the invoice before sending. You know this step is done when the Payment Request is saved and linked to the invoice with the expected outstanding amount.
Verify the email and the online payment link
The test request is sent to a mailbox you control. The tester checks that the email arrives, the sender, subject and invoice reference are correct, and the payment link opens the provider's checkout with the right amount and currency. Use the provider's test mode and test payment details where available, and record which payment methods the checkout offers. If the link fails or shows the wrong amount, correct the gateway account or the request before any live customer receives it. You know this step is done when a test payment completes through the link on the test mode checkout.
Confirm the Payment Entry and reconciliation
After the test payment, the finance lead checks that the gateway confirmation updates the Payment Request status and that a Payment Entry is created against the Sales Invoice, posting to the receiving bank account selected earlier. Confirm that the invoice outstanding amount drops by the paid amount and that the General Ledger entries match the expected accounts, including any gateway fees if your setup records them. Then check the bank reconciliation view so the receipt can be matched to the bank feed or statement line. You know this step is done when the invoice shows as paid, the Payment Entry posts to the expected accounts, and the receipt appears as matchable in bank reconciliation.
Document the approved process before live use
The finance lead and the administrator record the gateway accounts, default accounts, email template, who may create and send payment requests, and how failed or disputed payments are handled. Confirm access permissions for users who create requests and for those who can cancel or amend them. Keep a short written runbook so the same checks can be repeated after upgrades, credential changes or a new provider. You know this step is done when the runbook has been reviewed by finance and the administrator, and a second person can repeat the test request end to end.

Securing gateway credentials, links and recipients

Payment Requests connect a customer's inbox to a live payment gateway, so the risks sit in three places: the credentials that authorize charges, the people who can create and send requests, and the links that outlive the document they came from. The cards below list what to verify in your own ERPNext and gateway setup before the first request goes out.

Gateway account secrets

A Payment Gateway Account holds the keys that let ERPNext create charges at your provider. Confirm who can open the gateway configuration, where the API keys are stored, and whether the provider's test and live credentials are kept separate. Ask the provider which keys are restricted to payment creation and which can refund or read customer card data. Rotate keys on a documented schedule and after any staff change. Confirm that test credentials never reach the production site.

Who can create requests

Creating and sending a Payment Request is a permission decision, not a convenience setting. Review which roles can create, submit and email Payment Request documents, and whether sales users can send requests against orders they did not raise. Check whether a request can be created from a Sales Invoice with a different amount than the invoice total. Document the roles that may send requests to external recipients and keep that list short.

Role permissions on Payment Request

Permissions on the Payment Request DocType should separate drafting from sending and from reviewing. Test each role with a real user account rather than relying on the administrator view. Check read access on linked customers and suppliers, since a request exposes the amount and the party name. Confirm that users who can edit a request cannot also change the gateway account or the recipient email after the request is sent. Keep a written permission matrix that your auditors can read.

Email recipient checks

The payment link is only as safe as the address it is sent to. Before go-live, confirm how ERPNext picks the recipient, whether it uses the contact, the customer or a manually typed address, and who can overwrite that field. Test a request against a known mailbox and check the email headers. For outward requests to suppliers, verify bank details against the supplier master through a second channel before any transfer instruction is relied on.

Link expiry and reuse

A payment link can remain usable after the amount it represents has changed, the invoice has been cancelled or the customer has already paid by another route. Ask your gateway provider how long a hosted payment page stays valid, whether a link can be reused after a successful charge, and whether it can be cancelled from ERPNext. Build a routine that closes or cancels requests tied to cancelled documents, and confirm the duplicate payment handling in your reconciliation process.

Logging sent requests

Each request should leave a trail showing who created it, who sent it, to which address and with which gateway account. Confirm that Version tracking and document comments are enabled for Payment Request and that the retention period meets your policy. Decide where email delivery logs are kept and who may read them. Test that a sent request can be traced from the email back to the source Sales Order or Sales Invoice during a review.

What your finance team still has to do after the link is paid

A Payment Request does not post to the General Ledger. It records that an amount is owed and can be emailed with an online payment link, but the money movement itself is only accounted for once a Payment Entry is created and submitted against the invoice or order. Your team still needs to match the gateway settlement or bank credit to that Payment Entry, confirm the bank account it landed in, and check that the invoice outstanding balance has moved as expected. Month-end close should include a review of Payment Requests still in Requested or Initiated status alongside open receivables, so that paid-but-unrecorded items and unpaid links do not sit unnoticed. Confirm with your gateway provider exactly what its settlement reports contain, including fees, refunds and payout timing, because those details determine how much manual matching remains.

Build a written routine for the exceptions. A partial payment should be recorded as a Payment Entry for the amount received, leaving the invoice open for the balance, and the remaining Payment Request should be cancelled or reissued for that balance rather than left to be paid twice. A failed or abandoned payment needs a decision on whether to resend the link, switch to offline bank-transfer instructions, or write the request off, with the owner and date recorded. For disputed payments, agree who can cancel a request and who approves any refund, and make sure the customer contact and the invoice are reviewed together before anyone changes the record. Duplicate requests often come from re-sending from an order and an invoice at the same time, so the routine should include a periodic search for multiple open requests against one document and a rule for which one is kept. Assign these checks to named roles in your ERPNext permission model so the actions are traceable.

Treat the routine as part of your control design rather than a clerical task. Ask your auditors which evidence they expect for receipts, cancellations and refunds, then decide whether that evidence lives in ERPNext, your gateway dashboard or both. Run a test with a small set of illustrative transactions covering a full payment, a partial payment, a cancelled link and a duplicate, and confirm that the General Ledger, the receivables report and the bank reconciliation all agree at the end. Document the result so the next person can repeat it. The reconciliation approach itself is covered in the bank reconciliation topic, and this routine is what keeps the Payment Request layer from drifting away from the books.

Limits to confirm in your environment

Payment requests depend on a gateway account, a hosting model, a release line and a company structure, and each one can narrow what works. The cards below list the points to test with your gateway provider and on a non-production site before you rely on emailed payment links.

Gateway and currency support

Confirm which payment gateways your ERPNext release supports for your country, and which currencies each gateway account can settle in. A Payment Gateway Account must be configured before an inward Payment Request can carry an online payment link, so a missing gateway or currency blocks the whole flow. Ask the provider for written confirmation of the settlement currency, fees and refund handling, then send one test request through a test account to see the link and the resulting payment entry.

Frappe Cloud shared bench limits

Determine whether your hosting plan allows the features your payment flow needs. Server Scripts are disabled by default from version 15 and public shared benches do not allow them, so any custom logic around payment requests, such as routing rules or reminders, may need a dedicated bench or a self-hosted install. Check this before designing the process, not after go-live.

Version behavior for your release

Payment request behavior, gateway integrations and field names can change between major releases. Confirm which ERPNext line your organization will run and whether it is still supported, then test the exact version you plan to deploy. Supported lines and their end-of-life dates are published on the Frappe support page, and minor releases arrive often enough that a pinned version needs a documented upgrade plan.

Multi-company payment routing

If you run several companies on one site, confirm which company, bank account and gateway account each Payment Request uses, and whether a customer invoice from one company can trigger a payment link that settles into another company's ledger. Test a cross-company scenario with dummy customers and accounts before enabling the feature for staff who can send requests.

Partial payment handling

Check how the flow behaves when a customer pays part of an invoice, pays twice, or pays after a link has expired or been resent. Confirm that the payment entry allocates correctly against the Sales Invoice, that the outstanding amount updates, and that reminders stop once the balance is cleared. Record the expected results in a test script so accounts receivable staff know what each outcome looks like.

Questions buyers ask before setting up payment requests

How much does it cost to set up ERPNext payment requests?

Setup cost comes from the written scope, not a standard fee. Most of it is labor for configuring gateway accounts, payment request templates, email output and the accounts review of how each request posts later. Gateway fees charged by the payment provider are a separate, recurring cost you pay directly to the provider. The main cost drivers are the number of gateways, the number of currencies, the number of companies that send requests, and how tightly the payment step must connect to your receivables and bank reconciliation process. Ask for a quote that lists each gateway and currency as a separate line, states who configures the provider account, and says whether testing with live credentials is included.

How long does payment request setup take?

The build itself is usually short, but the calendar is often set by the payment provider. Account creation, identity checks, and approval to accept live payments can take longer than the ERPNext configuration, and that wait depends on the provider, not on the implementation team. Plan for the approval step to start early and run in parallel with configuration. Confirm the provider's current onboarding steps and expected review time directly with them before committing a go-live date, and make sure the written scope names which dependencies sit with you and which sit with the implementation team.

What do we need to provide before the work starts?

You need to supply the access and decisions that only your organization can give. This usually includes:

Payment gateway account credentials and the API keys or secrets the provider issues to you, handled through your approved secret store rather than email.
Bank account details for offline bank-transfer instructions, including the account for each currency and company.
Approval rules: who may create, send and cancel payment requests, and any amount limits that need a second approver.
Customer and supplier email templates, tax treatment and the Sales Order or Sales Invoice rules that trigger a request.
Named owners in finance who will test and sign off each posting outcome.

Can our internal team set up payment requests without a partner?

Often yes, for a single company, one currency and one gateway, provided someone on the team is comfortable with ERPNext roles, accounts and document workflows. Payment requests themselves do not post to the General Ledger, so the accounting risk sits in how the payment is later recorded against invoices and bank transactions. The harder parts are secure credential handling, multi-currency and multi-company behavior, and testing the full cycle from request to payment to reconciliation. Assess your team's experience with those areas honestly, and consider a fixed-scope review of the design if the team has not configured a payment gateway in ERPNext before.

How do we check that payment requests reconcile correctly?

Test the full cycle with non-production data before any customer receives a live link. A payment request records that an amount is due and does not post to the General Ledger, so you must confirm what happens when the customer pays. Check that the payment is recorded against the right invoice, that the bank transaction matches, that fees and currency differences are handled, and that cancelled or partially paid requests behave as your finance team expects. Document each test case and its expected accounting result so finance can repeat the check after upgrades.

Does DeployOpen issue compliance attestations for payment flows?

No. DeployOpen prepares systems, configuration, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. If your payment flow touches cardholder data or falls under a payment standard, confirm the scope with your assessor before design, since the choice of gateway and whether card data enters your environment largely determines what must be assessed. DeployOpen can document the configuration and evidence your assessor requests.

Can outgoing payment requests be used for supplier payments?

Yes, ERPNext supports outward requests for supplier payments in addition to inward requests to customers. Like inward requests, an outward payment request records the amount to be paid and does not post to the General Ledger on its own. Confirm with your finance team which supplier documents should trigger a request, who approves the payment, and how the eventual bank payment is matched to the purchase invoice. Treat supplier payment instructions as a higher-risk flow and include bank detail changes and approval controls in the design review.

How DeployOpen scopes and delivers ERPNext payment requests

DeployOpen plans and builds ERPNext payment requests and online payment links as part of a written scope, inside infrastructure you control. The work covers the gateway account, the request templates, the email path and the handover to your finance team, with each step agreed before build starts.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
We confirm which documents will trigger requests, such as Sales Orders or Sales Invoices, and which stay manual.
We list the payment gateway accounts, currencies and bank-transfer details the written scope will configure.
Ongoing support and upgrades can be added as a retainer after go-live.

How we build

We configure Payment Gateway Accounts and link them to the company bank accounts your finance team uses.
We set up outward Payment Requests for supplier payments and confirm they do not post to the General Ledger.
We test emailed payment links end to end in a non-production site before any customer receives one.
We document the approval and sending steps so the process is repeatable by your staff.

How we hand over

You receive the configuration, test records and a written list of the decisions we made during the build.
We walk your finance and sales staff through creating, sending and tracking requests and reconciling received payments.
Customizations are delivered as exported files in your own repository, so your team can review and maintain them.
We confirm with your payment provider and auditors which records, logs and reports they need to see.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We track ERPNext minor releases and plan upgrades on the version your team runs, after testing in staging.
We review payment gateway changes and email delivery issues when they affect requests.
We prepare the evidence your compliance team asks for, though independent auditors issue any assessment.