Key takeaways
- Payment links sent from a Salesforce record let customers pay securely without staff handling card details.
- Recurring and scheduled charges use gateway tokens, so card numbers never sit in Salesforce.
- Automatic retries and reminders recover many failed payments.
- Every transaction should be logged on the record for reconciliation, reporting and disputes.
Many service businesses still collect payments the hard way: staff take card details over the phone, re-type them into a terminal, and update Salesforce by hand. Recurring payments are tracked in spreadsheets, and failed payments are discovered weeks later. Salesforce can automate all of this.
Payment links
A payment link is a unique, secure URL sent to a customer by email or SMS. The customer opens a payment form hosted by the payment platform or on a secure Salesforce page, enters card or bank details, and pays. The result flows back to Salesforce automatically.
- Links should be unique to one payment and recipient, encrypted, and impossible to guess or alter.
- Links should expire after a time limit or once paid.
- The form should capture consent and, where needed, a signature for future charges.
- A receipt and a signed authorization record should be generated automatically.
Recurring and scheduled payments
For payment plans, subscriptions and installments, the first payment stores a token or customer profile with the gateway. Salesforce then schedules future charges against that token: monthly, weekly or on custom dates. Staff can see upcoming, completed and failed payments on the record.
Handling failed payments
| Step | What to automate |
|---|---|
| Retry | Retry soft declines on a sensible schedule, such as after a few days |
| Notify | Email or text the customer with a link to update their card |
| Escalate | Create a task for the account owner after repeated failures |
| Report | Dashboard of failed and recovered payments |
Reconciliation and reporting
- Log every request, response and error against the transaction record.
- Store gateway transaction IDs for matching with settlement reports.
- Report daily revenue, pending payments and failures by facility or entity.
- Sync payments to accounting software where needed.
Security essentials
Card data should go directly from the customer to the gateway through hosted or embedded forms. Salesforce stores only tokens, the last four digits, card type and expiry. This keeps your org out of the most demanding PCI scope and protects customers.
How we approach it
Our Payment Gateway for Salesforce package provides encrypted payment links, scheduled and batch processing, automated retries, multi-facility routing, signed authorization PDFs and complete logging, with Authorize.Net and CenPOS supported. You can see related work in our Authorize.Net and secure payment form case studies.
A worked example: a payment plan
A clinic agrees a six-month payment plan with a patient. Staff create the plan in Salesforce and send a payment link for the first installment. The patient pays on their phone and signs the authorization for future charges. Salesforce schedules the remaining five charges against the stored token. When the third charge is declined, the system retries after a few days and texts the patient a link to update their card; they update it and the charge succeeds. Staff never touched card details, and every step is visible on the record.
Questions to settle before building
- Which records initiate payments: invoices, opportunities, cases or a custom object?
- Who may send links, issue refunds or cancel schedules?
- How long should links remain valid?
- How should payments route across facilities or merchant accounts?
- Which accounting system needs the results, and how often?
Frequently asked questions
Do customers need a Salesforce login to pay?
No. Customers pay through a secure public form reached from their unique link.
Can we charge customers automatically every month?
Yes, with the customer’s authorization and a stored gateway token, scheduled charges can run automatically.
What happens when a recurring payment fails?
A good setup retries soft declines, notifies the customer with a link to update their card, and alerts staff after repeated failures.
