Not directly, and it need not. An AI agent can explain why a payment failed, send the customer a secure link to update their card or bank details, and confirm the change once it shows in the billing system. The customer enters the details themselves. Changes requested on someone else's behalf, or that redirect refunds, stay with a person.
Why should the agent stay out of the details themselves?
Two reasons, one about security and one about fraud.
Card numbers typed into a chat or read out on a call put the whole conversation, its transcript and every system that stores it inside the scope of card data security rules such as PCI DSS. A support agent that never sees card data keeps that scope small. The secure page handles the numbers; the agent handles the conversation.
The fraud reason is sharper. Changing where money comes from is low risk for the business. Changing where money goes, such as the bank account refunds or payouts are sent to, is a favourite target. A criminal who takes over an account and changes the payout details gets every future refund. That is the same pattern finance teams know from supplier bank detail changes, turned on customers.
What decides what the agent may do?
The direction of the money, and whether the customer is the one acting.
| Request | The agent may | Stays with a person |
|---|---|---|
| Update an expired or failed card | Send the secure update link to contact details on file; confirm when done | Customers who cannot use the link |
| Switch to a different payment method | Explain options; send the secure link | Methods that need a credit or eligibility check |
| Change the account refunds are paid to | Explain the process and start it | Approving the change, especially near a pending refund |
| Third party paying for the customer | Record the request | Checking authority and setting it up |
| Remove a payment method | Remove on the verified customer's request, if another valid method remains | Removal that leaves an active contract unpaid |
The agent's own permission in the billing system should be read-only for payment fields, plus the ability to send the secure link. That is a short list, and it should stay short.
An illustrative example
Take a subscription box company. A customer's monthly charge failed and they contact support.
The agent verifies the customer, reads the billing record and sees the card expired. It sends a secure update link to the email already on file and explains that the next attempt will run once the card is updated. The customer updates the card on the hosted page. The billing system confirms a valid method, and the agent tells the customer the charge will be retried tonight, because that is the scheduled retry in the system.
A different customer asks for an overdue refund of 120 to be sent to "my new bank account" which they type into the chat. The agent does not accept the details. It explains that refunds go back to the original payment method by default, and that changing the destination needs a separate check. The request is held for a person, who confirms it through a channel already on file.
The wider pattern of failed payments, retries and reminders is covered in how to handle payment failures for subscribers with an AI agent.
What controls make it safe?
- No payment data in conversation. The agent refuses to receive card numbers or full bank details in chat or voice, and tells the customer why.
- Links only to details on file. Secure links go to the email or phone already verified, not to one given in the same conversation.
- Refund destination changes held. Any change to where money goes is held for a named person and checked out of band.
- Read-only access for confirmation. The agent can see that a valid method exists and when it was added, not the full details.
- Linked-request checks. A contact-detail change followed by a payment-detail change in the same session is held, because together they look like takeover.
Payment fields are one row in a larger map of what an agent may write. The full map is in whether an AI agent can update customer records in a CRM.
Where Pryme fits
In Pryme, "send secure update link" and "change payout destination" are different capabilities, and the second is held for a person on any support agent. Bank details typed into a conversation are stamped as declared, and a declared claim cannot authorise money going out. More on support limits is in the AI support agent that knows when to say no.
Questions people ask
Can a voice agent take card details over the phone?
It should hand off to a secure capture method, such as keypad entry that bypasses the recording, rather than hear the numbers. The conversation then never holds the card data.
What if the secure link does not work for the customer?
The agent routes them to a person who can take details through an approved secure method. It does not fall back to taking the details itself.
Can the agent tell the customer which card is on file?
It can give the card type and last four digits so the customer can recognise it. It should not read out more than that.