Integrations
Payments
How the agent sends payment links from your payment provider during a conversation, while card details stay with that provider.
On this page
A payment is easiest to complete while the customer is still in the conversation. The agent sends a secure payment link from your own payment provider, for the amount taken from your systems, in the channel the customer is using. The customer pays on the provider's page, by card or with a digital wallet where your provider offers one, and the agent confirms once the payment is recorded.
The agent never sees or handles card details: they stay with your payment provider. Payment links are configured during implementation with your provider.
What connecting your payment provider lets the agent do
| Ability | What it means for you | Example |
|---|---|---|
| Send a payment link | A link for the exact amount due is created and sent in the conversation | A buyer receives a link for the registration fee on WhatsApp |
| Take the amount from your systems | The amount comes from the schedule, booking or invoice in your systems, not from the conversation | The next instalment on a payment plan, read from the CRM (the system that holds your customer records) |
| Confirm payment | The agent checks the payment's status with your provider and confirms to the customer | "Your payment has been received. Your reference is PAY-20455." |
| Follow up | Reminders for payments still due are sent within your contact rules. Configured during implementation | A reminder three days before an instalment falls due |
Integrations in this category
| Integration | What the connection covers |
|---|---|
| Stripe | Payment links and payment status |
| Network International | Payment links and payment status |
| PayTabs | Payment links and payment status |
| Apple Pay | Offered on your provider's payment page, where your provider supports it |
| Google Pay | Offered on your provider's payment page, where your provider supports it |
Apple Pay and Google Pay are digital wallets (ways of paying with a card stored on a phone). The customer chooses them on your payment provider's page; the agent's part is the same link.
How the connection works
When a payment is due in a conversation, the agent reads the amount from your system and asks your payment provider to create a link for that amount, with a reference that ties it to the customer and the booking, invoice or instalment. The link opens your provider's own payment page, where the customer enters their card details or chooses a digital wallet. Your provider processes the payment and tells your deployment the result.
Card numbers spoken or typed in a conversation are redacted (removed or masked) from transcripts and records. The agent never asks for card details; it sends the link instead. See Personal information redaction.
Refunds and payments for amounts not in your systems are decisions for your team. They are not connected to the agent, and a request for one is passed to your team.
The technical detail
The connection uses your provider's standard API (application programming interface: the documented way other software exchanges data with it) with credentials scoped to creating payment links and reading payment status, stored encrypted with AES-256 in your deployment. Payment status reaches your deployment through a webhook (an address your provider calls when a payment's status changes), and calls travel over TLS (Transport Layer Security), version 1.2 or higher. Because card data is entered only on the provider's page, it does not pass through or get stored in your deployment. The payment amount is inserted directly from the system record, not retyped by the language model.
Permissions typical for this category
| Permission | Needed for | Default |
|---|---|---|
| Create payment links | Sending a link for an amount due | Granted, for amounts read from your systems |
| Read payment status | Confirming payment to the customer | Granted |
| Issue refunds | Not needed | Not granted |
| Read stored card or customer payment methods | Not needed | Not granted |
The agent can only take actions your team has granted. Anything not granted cannot be invoked. See Permissions.
In practice
Sahel Crest Properties, a Dubai developer, uses payment links for instalments on off-plan units.
- The developer's finance team connects its payment provider and agrees the rule: links only for instalments on the payment schedule in the CRM.
- Three days before Fatima's next instalment falls due, the agent sends her a WhatsApp reminder with the amount from her schedule.
- She replies asking to pay now. The agent sends a link from the developer's provider. She pays with Apple Pay on the provider's page.
- The provider confirms the payment. The agent thanks her, gives her the reference, and records the payment confirmation against her record in the CRM.
What your team controls
- Which payments the agent can send links for, and the rules for each.
- Your payment provider and its settings, including which wallets are offered.
- Refunds, which stay with your team.
Related
- How integrations workIntegrations
- PermissionsIntegrations
- Personal information redactionSecurity and data protection
- Commitments and promise trackingCustomer record
- PropertyIndustry guides
Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.