Automated Sales & Payment Workflow with n8n – Case Study
Automated sales and payment workflow developed with n8n, artificial intelligence, WhatsApp Business, payment APIs, webhooks and PostgreSQL to manage commercial conversations, present service options, send payment links and continue the customer journey according to the transaction result.
This project was created for a business that needed to coordinate conversational sales and payment processing inside the same structured workflow.
The solution does not treat the conversation and the transaction as separate processes. Each lead maintains persistent information about the current commercial stage, previous decisions and payment status, allowing the automation to determine what should happen next even when different events occur at different times.
The Challenge
The commercial process required coordinating several elements simultaneously:
- WhatsApp conversations
- Customer decisions
- Service or commercial alternatives
- Payment links
- Payment confirmations
- Payment failures or incomplete transactions
- Post-payment actions
- Human intervention for special cases
Managing these elements manually increased the possibility of errors, delayed responses and loss of context between the conversation and the status of the transaction.
The business needed a system capable of understanding where each lead was in the process and coordinating conversational and transactional events as part of one continuous workflow.
The Solution
I developed an automated architecture using:
- n8n
- Artificial intelligence
- WhatsApp Business
- Payment APIs
- Webhooks
- PostgreSQL
- Persistent business states and rules
n8n operates as the orchestration layer connecting the conversation, commercial logic, payment process and stored state for each lead.
A simplified process can be represented as:
WhatsApp conversation → interpret request and current context → determine commercial option → send payment link when appropriate → wait for transaction event → process payment result → update state → continue conversation or escalate.
The system can coordinate actions that occur at different times without losing the relationship between the lead, conversation and transaction.
Conversational Sales Process
The workflow begins with the commercial conversation.
The system can interpret incoming questions and intent as part of the sales process instead of requiring customers to follow only rigid menu options.
Depending on the conversation, the automation can determine which information or commercial path should be presented next.
This creates a more flexible process where the conversation can evolve according to the context rather than following exactly the same sequence for every lead.
Commercial Options Based on Context
Not every lead necessarily reaches the same decision in the same way.
The workflow can use the current context to present different commercial alternatives according to the stage of the conversation.
This can involve:
- Understanding what the customer is asking
- Identifying previous decisions
- Determining which option corresponds to the current stage
- Presenting the appropriate next step
- Waiting for the customer’s response before continuing
The objective is to keep the commercial logic connected with the conversation rather than separating it into disconnected processes.
Payment Link Delivery
When the conversation reaches the appropriate stage, the system can send the corresponding payment link.
The workflow does not need to send payment information indiscriminately.
It can first evaluate the current commercial state and determine whether payment should be presented at that moment.
Conceptually:
Commercial decision → payment required → generate or retrieve payment link → send link → register payment stage.
This creates a clear connection between the conversation and the transaction that follows.
Persistent State Before and After Payment
One of the most important parts of the architecture is maintaining state throughout the complete process.
The system keeps information about what has happened before payment and what should happen afterward.
A lead may therefore move through states such as:
Commercial conversation → payment option presented → payment link sent → waiting for result → transaction processed → next action.
The exact state model depends on the business process, but the principle remains the same: the workflow must know where the lead is before deciding what to do next.
Payment Events Through Webhooks
Payment results do not necessarily occur while the customer is actively sending messages.
A person may receive a payment link and complete the transaction later.
Webhooks allow the payment system to notify the automation when a transaction event occurs.
The workflow can then process that event independently from the conversational message flow.
Conceptually:
Payment event → webhook → identify relevant transaction and lead → evaluate result → update persistent state → execute corresponding action.
This event-driven approach allows the system to react when payment information actually changes.
Confirmed Payments
When a payment is confirmed, the workflow can identify the successful result and update the commercial state accordingly.
This gives subsequent actions access to the correct transaction status.
Depending on the business process, the next stage may involve continuing the conversation, updating internal information or triggering another defined action.
The important point is that confirmation becomes part of the same persistent workflow rather than being managed separately.
Rejected or Incomplete Payments
Not every payment ends successfully.
The system was designed to distinguish between different transaction outcomes, including:
- Confirmed payments
- Rejected payments
- Incomplete payments
Different results may require different next actions.
A rejected or incomplete transaction should not necessarily follow the same path as a successful one.
By maintaining the transaction result as part of the lead state, the workflow can continue according to the actual situation.
Automatic Continuation After Payment
A key part of the project was allowing the commercial process to continue automatically after the payment result becomes known.
Instead of requiring someone to manually review the payment platform and then return to WhatsApp, the workflow can coordinate both events.
For example:
Payment confirmed → update state → continue appropriate conversation or process.
Or:
Payment rejected/incomplete → update state → follow the corresponding business route.
This connects conversational automation with transaction processing.
Persistent Business Logic
The automation does not depend only on the most recent message received.
Each lead maintains persistent information related to:
- Current commercial stage
- Previous decisions
- Payment status
- Relevant workflow state
This allows conversational and transactional actions to remain coordinated even when they occur at different moments.
That distinction is fundamental.
Without persistent state, a workflow may know that a payment webhook arrived but lack the context required to determine what that transaction means for the customer journey.
Duplicate Action Prevention
When conversations, delayed payment events and multiple workflow executions interact, the system must avoid repeating actions that have already occurred.
Persistent states help determine whether a particular step has already been completed.
This is useful for preventing situations such as:
- Reprocessing an already handled payment event
- Repeating the same commercial action
- Sending an inappropriate payment step twice
- Continuing from an outdated state
The exact controls depend on the workflow, but state-aware processing is central to maintaining a coherent customer journey.
Conversation, Lead & Transaction Traceability
The project also required maintaining traceability between:
- The conversation
- The lead
- The transaction
These three elements belong to the same commercial process.
Maintaining that relationship helps the workflow determine:
- Which lead a transaction belongs to
- What happened before payment
- What the payment result was
- What should happen afterward
This makes the automation much more useful than treating WhatsApp messages and payment notifications as unrelated events.
Human Handoff for Special Cases
Not every situation should be resolved automatically.
The system can escalate special cases to human attention when the workflow reaches a scenario that should not continue through the normal automated path.
This creates a hybrid model:
Automation manages structured conversational and transactional steps → exceptional situations can be transferred to a person.
The objective is to automate predictable processes while preserving human intervention where necessary.
Designed Around the Complete Customer Journey
The project was not designed as an isolated payment integration.
The real requirement was coordinating the complete sequence:
Conversation → commercial decision → payment → transaction result → next action.
That required considering:
- What the customer is asking
- What commercial stage they are in
- What decision has already been made
- Whether a payment link has been sent
- What the current payment status is
- What should happen for each transaction outcome
- When automation should continue
- When a person should intervene
The architecture was designed around that complete journey.
My Role in the Project
I was responsible for the technical implementation of the solution, including:
- Process analysis
- Design of states and business rules
- n8n workflow development
- WhatsApp integration
- Payment API integration
- Webhook processing
- Persistent database state
- Testing
- Debugging
- Handling exceptional scenarios
The project required coordinating conversational events and transaction events while maintaining consistent state throughout the process.
Technical Architecture
The solution combines several specialized components.
WhatsApp Business
Provides the conversational channel where leads interact with the commercial process.
n8n
Coordinates workflow execution, business rules, integrations, state transitions and automated actions.
Artificial Intelligence
Supports interpretation of questions and intent during the commercial conversation.
Payment APIs
Connect the workflow with the transaction process when payment is required.
Webhooks
Notify the automation when relevant payment events occur.
PostgreSQL
Maintains persistent information about the lead, commercial stage, previous decisions and payment status.
These components work together as a single business process rather than as independent integrations.
Reliable & Controlled Transaction Processing
Payment-related workflows require stronger controls than a simple message automation.
The system needs to consider:
- Which customer the transaction belongs to
- Whether payment was actually requested
- Whether an event has already been processed
- The current transaction status
- The current commercial state
- Which action corresponds to each result
- Whether human intervention is required
The workflow uses persistent information and explicit business states to maintain control over these decisions.
The Result
The project produced an automated sales and payment workflow capable of coordinating conversational and transactional steps within one process.
The system can:
- Interpret questions and intent during the conversation
- Present different commercial alternatives according to context
- Send payment links when appropriate
- Maintain state before and after payment
- Receive payment events through webhooks
- Identify confirmed, rejected or incomplete payments
- Continue the process automatically according to the result
- Help prevent duplicate actions through persistent states
- Escalate special cases to human attention
- Maintain traceability between conversation, lead and transaction
The result is a connected sales workflow where payment becomes part of the customer journey instead of a separate process that requires manual coordination.
What This Project Demonstrates
This case study demonstrates practical experience combining:
- n8n workflow automation
- WhatsApp Business
- Artificial intelligence
- Conversational sales automation
- Payment API integrations
- Payment webhooks
- PostgreSQL
- Persistent business states
- Transaction status handling
- Business rules
- Duplicate-action prevention
- Human handoff
- Multi-step sales workflows
It also demonstrates an important architectural principle:
A payment event only becomes operationally useful when the system understands the commercial context surrounding that transaction.
Related Services
This project is a practical example of several broader services available on Mi-Tienda.com.co.
I would internally link this section to:
Sales Automation & Lead Follow-Up
AI Integrations with CRM, WhatsApp & APIs
Need an Automated Sales & Payment Workflow?
Tell me how your process moves from conversation to payment and what remains manual.
If your team handles sales conversations through WhatsApp and then manually sends payment information, checks transactions, updates customer status or returns to the conversation after a payment event, those steps may be suitable for automation.
I can review:
- Your current sales conversation
- Commercial stages and decisions
- Payment process
- Payment provider API capabilities
- Webhook events
- Customer and transaction states
- Database requirements
- Post-payment actions
- Error and exceptional scenarios
- Human handoff conditions
Tell me how your current process moves from conversation to payment and what your team needs to do manually before and after the transaction.
From there, I can evaluate the most practical automation architecture.
WhatsApp: +57 318 648-4818
FAQ: Automated Sales & Payment Workflow
What is an automated sales and payment workflow?
It is a system that connects commercial conversations, business rules and payment processing so actions can continue automatically according to the customer's current stage and transaction result.
Can a WhatsApp conversation trigger a payment process?
Yes. In this project, the workflow can determine when the commercial process has reached the appropriate stage and send a payment link when required.
Can the workflow understand what the customer is asking?
Artificial intelligence formed part of this implementation to interpret questions and intent during the commercial conversation.
Can different commercial options be presented according to context?
Yes. The system can use the current conversation and commercial state to determine which alternative or next step should be presented.
How does the system know when a payment link has already been sent?
Persistent states allow the workflow to maintain information about the current stage of the process, including actions that have already occurred.
How are payment results received?
Payment events are received through webhooks from the connected payment process.
Can the workflow detect whether a payment was successful?
Yes. This implementation distinguishes between confirmed, rejected and incomplete payment results.
What happens after a payment is confirmed?
The workflow updates the relevant state and can continue with the next action defined for a successful transaction.
What happens if a payment is rejected or incomplete?
The transaction result is recorded and the workflow can continue according to the business route defined for that situation.
Does the system need the customer to send another WhatsApp message after paying?
Not necessarily. A payment webhook can trigger the next workflow action when the transaction result becomes available.
Why are persistent states important?
They allow the automation to know the commercial stage, previous decisions and current payment status even when conversational and transactional events happen at different times.
Can duplicate payment actions be prevented?
Persistent states and process rules can help prevent actions from being repeated when an event or transaction has already been handled.
Why is PostgreSQL used?
PostgreSQL maintains persistent information related to leads, commercial states, previous decisions and payment status across different workflow executions.
Can special cases be transferred to a person?
Yes. The architecture can escalate exceptional scenarios to human attention when they should not continue through the normal automated route.
Can a similar workflow be adapted to another business?
Potentially yes. The sales stages, payment provider, transaction events, business rules, persistent states and post-payment actions need to be reviewed for each implementation.