Payment Methods in Chat: Answering Questions Before Checkout

The cart is filled, the delivery address is entered, and then one question remains that has nothing to do with the product any more: can I pay by invoice? Is the direct debit collected straight away? Does the payment method cost extra, and when does the order ship with payment in advance? In almost every shop the answers sit somewhere in the payment and shipping terms, rarely where the visitor is hesitating. This article shows how a chat assistant answers these questions from exactly those terms, with the source and without promising a payment method the shop only checks during the order process. It explains what the law says about means of payment and fees, why account numbers and card details do not belong in the chat window, and at which point a person takes over.

Enlarge graphic

Labels in the illustration

• Stated in the terms
• Checked case by case
• Personal matter
• Example question
• Source
• Reply in chat
• “Do you offer direct debit,
• and when does it ship?”
• Payment terms,
• section payment methods
• Reply with its source,
• shipping start per method
• taken from the terms
• “Can I pay by invoice
• or in instalments?”
• Terms name the check,
• not its outcome
• State the condition, no
• promise; the checkout
• decides
• “My payment was declined.
• What now?”
• Only in the shop’s payment
• system, not in the chat
• Handover to your team
• with the history, without
• payment data in the chat
• Payment happens at the shop’s checkout
• No account numbers, card details or login data in the chat; the cart link leads into the shop.
• Shop checkout

Payment questions in chat: three kinds of answer

The question just before paying

Anyone who reaches the payment step has decided on the product. What remains open is how, and on which terms, to pay. Overall, averaged across 50 studies, 70.22 % (Baymard Institute) of online shopping carts are abandoned; the figure does not say at which point in the ordering process. Not every one of these abandonments is about payment, some come from visitors who are only browsing or comparing prices. An open payment question just before paying, however, is among the reasons that a short, correct answer can settle, because the answer already exists in the shop.

The problem is rarely missing information but its location. The payment methods sit in a footer, the conditions for buying on invoice in the terms and conditions, the shipping start for payment in advance in the delivery terms, and the payment deadline only on the invoice. Someone in the middle of the order process does not like to leave it to read four pages. How a conversation closes this gap at the right moment without being intrusive is covered in the article recovering cart abandonment with chat.

• Invoice: Can I buy on invoice, and by when do I have to pay?
• Payment in advance: When does it ship if I pay by bank transfer, and how long is the item reserved?
• Direct debit: When is the amount collected, on ordering or on shipping?
• Instalments: Is financing available, and from which order value?
• Fee: Does a payment method cost extra?
• Security: Where do I enter my details, and who sees them?

What the shop must state beforehand

A chat does not replace a mandatory disclosure, it makes it accessible. For websites in electronic commerce with consumers, Section 312j (1) BGB of the German Civil Code requires that the accepted means of payment be stated clearly and unambiguously at the latest when the order process begins. The rule addresses the shop, not the assistant. For the conversation it has a practical consequence: the list of means of payment already exists in binding form, and the assistant has to reproduce it, not reword it.

On top of this come the general information duties in distance selling. Article 246a Section 1 (1) sentence 1 No. 10 EGBGB, the Introductory Act to the German Civil Code, expressly lists the terms of payment, delivery and performance among the information the trader must provide to the consumer, together with the date by which delivery will be made. Payment method and shipping start therefore sit side by side legally, and in conversation they are linked anyway: whoever asks about payment in advance usually wants to know when the goods will arrive.

The source: payment terms, not general knowledge

A language model knows from training which payment methods are common in online retail. That very knowledge is dangerous here, because common is not the same as offered. An assistant that answers a question about buying on invoice with a general yes, because many shops offer it, creates an expectation your shop may not meet. XICBOT ties answers to the retrieved context: factual statements as a rule carry a source reference pointing to where it was found, and an answer that remains without a source is recorded as a gap and, from the Pro package, shows up in the analytics. What that reference looks like in the chat is shown in the article citing sources in chat.

Payment methods are not in the product catalogue but in your documents. With the shop assistant, item data comes from your shop’s catalogue based on Shopware Community Edition; shipping, returns and payment methods are added to the knowledge base as documents, and the assistant quotes from them with the source. For these documents to carry the load, they should contain more than a row of logos.

• Every payment method offered, under the name it also carries at the checkout
• Conditions per payment method, such as delivery country, order value or customer account, where such limits exist
• Time of the charge or collection, and the payment deadline for purchases on invoice
• Shipping start per payment method, for example after receipt of payment or after a successful check
• Fees for a payment method, if you charge any, with their place in the terms
• What happens when a payment is declined, and the contact route for it

Invoice, advance payment, direct debit: what people ask

The questions about individual payment methods are predictable, and that is an advantage: they can be collected before go-live and tested against the terms. Behind each question there is a specific piece of information that has to be in the documents for the assistant to answer it reliably.

What stands out is how often the same question needs two answers. “When will it be collected?” is a payment question, “when will it ship?” a shipping question, and both depend on the same payment method. That is why payment and shipping terms belong side by side in the knowledge base, with clear sections, so that the assistant does not derive a delivery time for direct debit from a sentence about advance payment.

What the shop checks case by case

Buying on invoice and paying in instalments are rarely unconditional. Often a check during the order process decides whether the payment method is offered for this particular order, depending for example on the delivery address, the order value or the history of the customer account. The assistant does not know the outcome of that check, and it should phrase its answer so that nobody reads the outcome into it.

• Breaks: “Yes, you can buy on invoice with us.” That sounds like a promise for this exact order.
• Holds: “According to our payment terms we offer purchase on invoice; whether it is available for your order is shown at the checkout after a check.”
• Breaks: “Instalments are no problem even for small amounts.” Neither the amount nor the outcome is settled.
• Holds: “Instalments are possible from the order value stated in the terms and require a separate check.”

Fees for means of payment

“Does paying by card cost extra?” is one of the questions where a wrong answer does double damage: it annoys the customer and may hold out an agreement the law does not support. Section 312a (4) BGB limits fees a consumer is to pay for using a particular means of payment.

For certain means of payment, Section 270a BGB goes further: an agreement on a fee for using a SEPA core direct debit, a SEPA business-to-business direct debit, a SEPA credit transfer or a payment card is invalid, for payment cards with a restriction the provision itself sets out. For the assistant this does not mean it should assess fees legally. It means that a fee stated in your terms should be checked before go-live, because the assistant repeats what is written there.

When the goods are on their way

The most common follow-up question about the payment method concerns shipping. With advance payment the delivery time usually starts on receipt of payment, with purchase on invoice after a successful check, with direct debit and card often straight after ordering. Which of these rules applies to your shop is stated in the delivery and payment terms, and that is exactly where the assistant picks it up. How it gives delivery times as a range rather than a date is described in the article shipping and delivery questions in chat.

With purchase on invoice, the next question is the payment deadline. It is in your terms or on the invoice, and the assistant gives it from there. The law also has a fallback rule on default: under Section 286 (3) BGB the debtor of a payment claim is in default at the latest if he does not pay within 30 days of the due date and receipt of an invoice; towards a consumer this applies only if the invoice specifically pointed out these consequences. This rule is not a payment term the assistant should offer, but background that shows why payment deadlines should be stated unambiguously in the terms.

No payment data in the chat window

A chat is not a payment channel. IBAN, card number, security code or login details for a payment account belong in your shop’s checkout, where they are processed for exactly this purpose. In the chat they would end up in a conversation history that is stored for analysis and handover and is not meant for them. The General Data Protection Regulation requires personal data to be adequate for the purpose and limited to what is necessary; answering a question about payment methods requires no payment details.

With XICBOT this separation is part of the design: no order and no payment is created in the chat, and checkout, payment and shipping stay in the shop. The cart assistant puts together a cart in the conversation, and “Continue” leads into your shop. The customer places the order there, in the ordering situation in which, under Section 312j (3) BGB, they expressly confirm that they are committing to a payment. What a visitor types into the input field of their own accord cannot be prevented; all the more important that the assistant does not ask for it itself.

• Record in the assistant’s rules that it does not ask for account numbers, card details or login data
• Answer security questions with the place where data is entered: the shop’s checkout
• If a visitor sends payment data anyway, do not repeat it and refer to the checkout
• Delete conversation logs after a fixed period so that data entered by mistake does not stay for good

When a payment gets stuck

Beyond a certain point a payment question is no longer a request for information but a case: the payment was declined, an amount was charged twice, a direct debit was returned, a payment reminder has arrived, or someone is waiting for a refund after a withdrawal. Such cases concern a customer account, an order and often money that has already moved. They belong with a person who is allowed to look into the systems.

With XICBOT the handover to a person is available in every state of the conversation, not only after a failed attempt. If nobody is available at the moment, the assistant says so openly and offers an asynchronous route. How to design the handover so the customer does not have to repeat anything is described in the article handover to human agents.

What can be measured

Payment questions are easy to analyse because they use recurring terms. Conversation analytics shows, from the Pro package, what people really asked, and every answer that remained without a source appears as a line of its own in the gap list. From this you can see which payment method is described too briefly in your terms, which question about fees or security keeps coming back, and at which point conversations go to your team after a payment question.

What cannot be measured is how many orders would not have been placed without the answer; there is no comparison group for that. A specific increase in the conversion rate therefore cannot be promised. What can be influenced is whether a payment question gets a correct answer at the decisive moment, and that can be read in every single conversation.

Frequent questions