How do bank aggregated payment merchants connect to pay-and-invoice? Kailing Technology Leqi joint usage solution connects transactions, funds, and invoices

During the lunch peak, payment success notifications sounded continuously at the checkout counter of a chain restaurant store. Consumers scanned the aggregated payment QR code to complete payment and immediately asked the waiter how to issue an invoice. The merchant checkout system holds the table, dishes, and order, the bank or aggregated payment platform holds the channel transaction and fund status, and consumers only see one payment on their phones. Each of the three parties has a segment of data, but there is a lack of an order mainline that can continuously advance transactions, funds, and invoices.

Kailing Technology's Leqi joint-use solution starts from this order: it maps the merchant business order, platform payment order, invoicing request, and tax result to the same business relationship, determines the trigger point according to merchant rules, collects buyer supplementary information, and sends the issuance status back to the merchant and consumer entry. Kailing Technology handles business orchestration and interface implementation, while payment acceptance continues to be completed by the bank or aggregated payment platform.

▍Before the first order goes live, first map out the four-party operating relationship

The operation diagram fixes four business roles: consumers initiate payment and invoicing applications, merchants provide goods and services, sales entities, and order status, banks or aggregated payment platforms as direct connection units form original records of transactions or fund receipts and payments in their own systems, and tax capabilities receive requests and return processing status. Merchants connect as user units after invitation and confirmation.

Kailing Technology does not occupy a role card, but acts as the business orchestration and interface implementation party, connecting merchant cashier, mall, or order systems with the direct connection unit interface, and organizing payment triggers, buyer information, invoicing requests, result callbacks, and exception compensation. What data each role provides and what status it receives is marked item by item before joint debugging.

After the relationship is clarified, consumers receive the invoice from the original payment or order entry, merchants maintain the real order and invoicing rules, the direct connection unit provides the joint-use channel, and the tax capability returns the invoice result. The Kailing implementation team organizes the four-party handover into a traceable status loop.

▍Behind the payment QR code, traceable original transaction records must be retained

When the consumer scans the code, the merchant system first generates a business order, recording the store, sales entity, goods and services, tax-inclusive amount, and transaction time; the aggregated payment platform or bank generates a payment order, recording the channel, payment status, and fund transaction. The two systems each retain their original numbers, then establish a mapping through a unified business key.

When multiple payments of the same amount appear during the lunch peak, the interface does not guess based on amount and time. The payment callback carries the platform order relationship, the business orchestration layer finds the corresponding merchant order, verifies the sales entity and receivable amount, and then updates the status. The cashier can see transaction completion and payment success on one order.

Dine-in checkout, delivery, retail outbound, or parking exit each have different business completion points. The project configures trigger actions for specific scenarios: some enter pending invoicing as soon as payment succeeds, while others wait for outbound or service completion. The payment signal and business status together determine the next step.

▍Merchant invoicing rules are validated before request generation

After payment succeeds, the system reads the store's sales entity, item mapping, invoiceable types, invoicing quota, and already invoiced amount of the order. Dishes, service fees, or retail goods generate invoicing items according to the mapping maintained by the merchant, and cashier notes do not directly become tax fields.

The rule engine simultaneously checks whether the order is canceled, whether a refund has occurred, whether an application has already been made, and whether the amount is occupied by other requests. Orders meeting the conditions enter an applicable state; orders hitting exceptions enter the operations to-do list, and the reason is sent back to the merchant workbench.

When multiple stores share one aggregated payment entry, the system selects the corresponding invoicing configuration based on the entity the order belongs to. Headquarters can view operations across all stores in a unified way, stores only process their own orders, and data permissions and invoicing entities are automatically assigned according to business relationships.

▍After consumers supplement buyer information, invoicing is initiated along the original order

The consumer clicks to invoice on the payment bill, merchant mini program, or order page, and the system automatically brings out the merchant, order, amount, and invoiceable items, leaving the consumer to supplement only the personal or company title, tax number, and receiving method. The filling process always references the original payment order and does not create a separate piece of data detached from the transaction.

After the consumer submits, the system first validates required fields and title format, then merges the buyer information with the merchant invoicing rules into a request. Repeated clicks query the existing status along the same business key, and the page displays processing or completed, preventing cashiers from repeatedly submitting manually.

Scenarios that do not require buyer information can reduce input steps according to the merchant plan; when a company title is needed, consumers can save commonly used information. During store peak hours, the online entry handles invoice requests, cashiers focus on transactions, and operations staff only handle the exception queue.

▍Payment triggering, issuance, and result callback form a status loop

After the invoicing request enters the tax capability, the system records submitted, processing, success, or failure. The success result carries the invoice number, issuance time, and file information back to the business orchestration layer, then writes back to the merchant order and pushes the consumer collection entry.

When the tax side has already issued but the merchant write-back temporarily fails, the compensation task repeatedly pushes the same result without re-initiating issuance. Consumer entry delivery failures are also recorded separately, and operations staff can resend the notification while the invoice itself remains unique.

That lunch order at the restaurant store finally shows payment successful, invoice issued, and consumer claimed. The merchant views the invoice from the order, the consumer views the file from the payment entry, and headquarters views the full-chain status from the operations console, with the three entries pointing to the same result.

▍Refunds and red-letter reversals update the invoicable amount in reverse along the original order

After paying, the consumer discovers a dish return, and the merchant system first generates a refund business and links it to the original order. After an uninvoiced order completes the refund, the invoiceable amount decreases with the refund result; an already invoiced order enters red-letter processing, the red invoice establishes a relationship with the original blue invoice, and the processing status is sent back to the merchant and consumer.

For partial refunds, the system calculates the adjustment scope according to the original order details and merchant rules, retaining the consumed portion and refunded portion. Refund applications, payment channel returns, red-letter results, and remaining invoiceable amount advance on the same timeline, and operations staff do not need to manually splice between the payment ledger and invoicing ledger.

When an interface timeout occurs at a refund or red-letter reversal node, the system first queries the original request, then performs write-back or resubmission. The test team uses three samples to accept the reverse chain: refund not invoiced, fully refunded after invoicing, and partially refunded after invoicing, confirming that each step has an entry, status, and handler.

▍Daily reconciliation directly locates differences in transactions, funds, and invoices

After market close each day, the merchant reconciles business orders, platform payments, invoicing requests, and invoice results by a unified business key. The system places payment succeeded pending invoicing, invoiced pending callback, refund completed pending red-letter reversal, amount inconsistency, and duplicate applications into separate processing queues.

Finance can click a difference to see the merchant order number, platform transaction number, invoicing request number, and current status. When the payment amount and order amount are inconsistent, it returns to business verification; when issuance succeeds but the consumer has not claimed it, it transfers to delivery re-push; when red reversal is complete but the merchant has not updated, status compensation is executed.

Headquarters views exception types and processing duration across stores, stores view their own orders, and the platform or bank views merchant operations according to authorization. Reconciliation changes from month-end summary differences to same-day cleanup by status, and problems are resolved at the node where they arise.

▍Pilot at one peak store before replicating merchant integration

The first pilot selects a store with a clear order structure and a stable cashier system, and continuously runs through payment success, consumer supplementary entry, issuance callback, claiming, refund, and red reversal. Acceptance personnel observe concurrent submission and callback order during the lunch peak, and also check the complete ledger after closing.

After the pilot passes, the project team consolidates merchant entities, stores, invoicing items, interface authentication, status codes, exception compensation, and permission templates. When new merchants onboard, the technical skeleton is reused, and differences are configured according to industry transaction completion timing and invoicing rules.

Implementation judgment focuses on whether the original records enter the platform's own system, whether merchant orders are stable, whether the trigger point is clear, and whether reverse transactions are testable. Kailing Technology orchestrates transactions, funds, and invoices into one operating chain, with the bank platform, merchants, and tax capabilities continuously providing real status at their respective nodes.

▍FAQ

Q: What is Kailing Technology responsible for in an aggregated payment-triggered invoicing project?

A: Kailing Technology is responsible for enterprise-side business orchestration, system interfaces, invoicing rules, status callback, and exception compensation, while payment acceptance is completed by the bank or aggregated payment platform.

Q: Will consumers receive an invoice immediately after successful payment?

A: The system triggers based on the merchant business completion status and invoicing rules; once conditions are met, a request is generated, and the issuance and delivery status are returned to the original order.

Q: Will repeated clicks by consumers to issue an invoice generate multiple invoices?

A: A unified business key and request status are used to identify duplicate operations, and the page prioritizes querying existing results.

Q: How is the invoice-payment relationship handled after a partial refund?

A: Refunds, payment channel results, red-letter processing, and the remaining invoicable amount are updated along the original order, and operations staff can view them on the same timeline.

Make aggregated payment orders, fund results, and invoice status continuously traceable. Learn about Kailing Technology's Leqi combined use solution: https://www.kailingteck.com/leqi-zhilian/ .

As a national high-tech enterprise, Kailing Technology focuses on the digital and intelligent transformation of enterprise business-finance-tax and operations management, providing software products, system integration, implementation and delivery, and operational services for various government agencies, institutions, group enterprises, and SMEs.

The company has now formed ten core product lines, including: AI digital employee system, enterprise expense control management system, customer relationship management system, reverse invoicing management system, invoice issuance for individuals management system, electronic archives management system, tax fully digitalized e-invoice Leqi system, tax invoice management system, group tax filing system, and AI OCR recognition system. It is committed to connecting enterprise business, finance, tax, funds, and archive data to help customers improve operational efficiency, business-finance-tax compliance capabilities, and digital management levels.

If you have any business-finance-tax digital transformation needs, welcome to contact us. Beijing Kailing Technology will serve you wholeheartedly.

Keywords: bank aggregated payment, pay-and-invoice, Leqi joint usage, merchant invoicing, transaction funds invoices