Skip to CRM content

121 CRM feature · Payment links

Make a payment request recognisable, controlled and easy to reconcile.

Share an approved payment link for a defined purpose, then keep status and follow-up connected to the customer journey. The capability is described from official product evidence; its availability, configuration and any usage charges for a particular 121 account still need to be confirmed before reliance.

Fictional product demonstration

See payment links in the context of real customer work.

This coded interface uses realistic fictional data to explain the operating pattern; it is not a screenshot of a live customer account.

121

Northstar Joinery

Keep payments and customer records connected

AR
OverviewPaymentsInvoicesOrdersProducts

Keep payments and customer records connected

See invoices, orders and products alongside the customer journey while keeping reconciliation visible.

Recorded this month

£2,240

Illustrative total

Open invoices

2

One draft, one sent

Orders

3

Across three customers

ReferenceCustomerIssuedTotalStatus
INV-1048Marlow Works8 Oct£1,240.00Sent
INV-1047Oakfield Homes6 Oct£680.00Paid
INV-1046Bramble Studio2 Oct£320.00Draft
Illustrative 121 interfaceAll people, organisations, dates and activity are fictional. Any figures are illustrative. Controls demonstrate interaction patterns, not enabled account features.

How it helps

See how the feature supports the work.

Each part has a clear job. It becomes useful when it fits the way customers already move through the business and your team knows when to step in.

Capability 01

Payment links

Creates a shareable checkout for configured products and prices.

How it works
Uses configured products, merchant connections and checkout rules for an eligible payment or order journey.
Why use it
Lets a customer pay through a focused, reusable link without a bespoke checkout build.
Plan for
Provider fees, tax treatment, disputes, settlement and feature eligibility remain separate responsibilities.
Your team owns
A responsible person must approve prices and terms and resolve refunds, disputes and fulfilment exceptions.
Capability 02

Payment providers

Connects a supported merchant provider before the sub-account can accept eligible payments.

How it works
Uses configured products, merchant connections and checkout rules for an eligible payment or order journey.
Why use it
Keeps payment processing under an explicit merchant account and provider relationship.
Plan for
Provider fees, tax treatment, disputes, settlement and feature eligibility remain separate responsibilities.
Your team owns
A responsible person must approve prices and terms and resolve refunds, disputes and fulfilment exceptions.
Capability 03

Contacts

Stores a person or lead with contact details, activity, ownership and related records.

How it works
Stores or organises supported business data under configured fields, permissions and record rules.
Why use it
Gives a team one place to understand who a customer is and what has happened.
Plan for
The platform does not make imported, duplicated or incomplete data accurate without review.
Your team owns
A data owner must define the record model and resolve quality, ownership and access exceptions.
Capability 04

Actions

Performs supported steps such as sending a message, updating a record, assigning work or calling a connected service.

How it works
Runs an ordered sequence only after its configured trigger and conditions are met.
Why use it
Coordinates routine execution across the customer journey.
Plan for
Automation follows its configuration; it cannot repair poor data, unclear rules or an unavailable external service.
Your team owns
A process owner must approve, test, monitor and pause or correct faulty automation.

Use it with purpose

What good payment links looks like

A fictional workshop provider sends a link for an agreed place only after the attendee has seen the date, price and terms. The useful outcome is a record that another person can understand and continue, not simply another automated event.

Create for a clear purpose

Link the request to an approved product, amount or commercial step.

Explain before sending

Tell the customer what they are paying for and which business is taking payment.

Reconcile the outcome

Confirm successful, failed or disputed outcomes through the provider and appropriate business records.

Configuration decisions

Decide the operating rules before switching payment links on

A credible setup begins with ownership, eligibility and exception decisions. Those choices should be written in plain English and tested with realistic fictional data.

Control link creation

Limit who may create or change links and where approved links are stored.

Check the customer journey

Test the page, receipt, failure route and return experience before use.

Human review point

Plan exceptions

Define what happens for duplicate payment, refund request or customer query.

From configuration to daily use

Keep the rule, the owner and the exception visible

The second view shows how the capability connects to work a person can review and continue.

121 CRM · Workflow sequence

Enquiry received

Capture source and customer

Acknowledgement

Set a clear response expectation

Human review

Check fit, consent and exceptions

Owner assigned

Name the person responsible

Follow-up due

Remind the owner, not the customer blindly

Illustrative exampleA conceptual workflow. Triggers, messages, delays and exceptions need configuration and testing.

Practical example

Follow one example from signal to next action

A fictional workshop provider sends a link for an agreed place only after the attendee has seen the date, price and terms. The example shows the role of the CRM while keeping the consequential decision with a person.

Place agreed

The customer confirms the workshop and price.

Link selected

Staff use the approved payment link for that offer.

Human judgement

Customer pays

The provider handles the secure payment step.

Status checked

The team verifies the outcome before confirming the place.

Boundaries and checks

Plan for the limits of payment links

Product capability is only one part of a dependable process. Data quality, provider configuration, consent, permissions and staff cover still matter.

Data and context

A link does not prove that a payment settled or belongs to the right account.

Account and provider setup

Provider fees, currencies and availability require configuration checks.

Keep a person accountable

Human responsibility

Never expose payment execution as a public agent action.

Questions about this page

Useful answers, without the sales fog.

1. Is payment links confirmed as included in every 121 CRM account?

No. The underlying capability is evidenced in official product documentation, but 121 plan entitlement, sub-account configuration, connected providers and usage charges have not been assumed. Confirm the intended setup before relying on it.

2. What should we decide before configuring payment links?

Start with three decisions: control link creation, check the customer journey, plan exceptions. Then test ordinary, missing-data and exception cases with fictional records.

3. What is a practical way to measure whether payment links is helping?

Measure whether the intended customer work becomes visible and owned. For this page, review create for a clear purpose, explain before sending, reconcile the outcome rather than treating clicks, sends or record counts as proof of business value.

4. Can payment links be fully automated?

No. Never expose payment execution as a public agent action. Automation can coordinate repeatable steps, while people remain responsible for judgement, exceptions, consent and correcting the record.

Read all CRM questions

Delegate the work. Keep the human.

Ready to organise the customer journey?

Subscribe through the approved secure checkout, or review pricing and responsibilities before you decide.

121 CRM

Your customers. Your conversations. Your business. Organised around clear ownership and human decisions.