Customer notifications, auction participation, payment after a winning bid, and service operations are one user experience. At company B, a live commerce service for collectible toys, we built development, cloud, customer messaging, and payments together and carried on with QA and operations after launch.
When building an auction-format live commerce service, a finished broadcast screen is not enough to start the service. Customers have to know that a broadcast is opening, and the transactions they take part in have to lead to payment. The operations team has to be able to confirm what happened along the way.
Company B was preparing a new live commerce service for collectible toys. Alongside the development deliverables, the environment the service would run on, the notifications going out to customers, and the path money would travel were all needed on the same launch schedule.
IXC's job did not end with installing each solution. It was to connect different functions so that they work as one service for the customer.
Four pieces of work shared one launch schedule
Building development, infrastructure, messaging, and payments well individually matters too. But the completion of each piece does not mean the whole user flow is complete.
A function the customer notification needs may not be in the app yet, or the service may not move to the next state even after receiving a payment result. These connection points show up when the whole flow is viewed together rather than each part on its own.
At company B, the cloud environment and deployment path were prepared to match the development schedule, and the messaging integration and payment build proceeded within the same schedule. The conditions for rolling back the environment transition were set out as well.
The point of this approach is not only that it reduced the number of companies involved. It is that the conditions and the order of dependency for each change were handled within one schedule.
Customer notifications were built to the starting point of operations, not just installed
Customer messaging covered SDK integration, channel setup, and the configuration of base campaigns together. It created the touchpoint between broadcasts and customers, and prepared a starting point from which operators can expand campaigns later.
A notification function is not complete simply because messages can be sent. It needs the operating context of whom to contact in which situation and where the customer goes after receiving the message.
System integration and campaign results have to be told apart, however. Connecting a channel does not by itself mean customers will come back more often. Adjusting the audience and content of messages by watching customer responses continues in operations.
The build scope of this project was to put the basic structure in place so that those operations could begin.
Before payment success, we defined the states of payment
For payments, the states of authorization, cancellation, and partial refund were defined before integration. A unique identification standard and retry rules were set to reduce duplicate handling of the same request, and failure paths were also checked in the test environment.
Thinking about payment exceptions shows why state definitions are needed. When a request has been sent and no response comes back, should the service treat it as a success or a failure? Retrying unconditionally or marking the order as failed is not enough.
The property that keeps a transaction from being applied twice even when the same request is repeated is called idempotency. More important than the name is whether the one transaction the customer intended is traced as that transaction in the system.
In a payment integration, it is not enough to check that the payment window opens. What state the service leaves behind when the response is not as expected has to be examined as well.
Points were not left as a separate number either
Point top-up and management functions were added for company B as well. The configuration manages two kinds of transactions, payments and points, as connected records.
A point balance is a number shown on screen, but in operations it has to be possible to explain why the number is what it is. Top-up history and usage history have to be understood separately before customer inquiries can be answered.
This build handled the connection between payment and point transactions. We set out which records each should reference when a transaction occurs, so that the purchase process and point management did not remain disconnected functions.
It shows that as transaction functions multiply, the connection of transaction records has to come before the variety of buttons.
Verification and operations continued after launch
After launch the service moved into operations, and cloud operations and release QA continued. Changes after the build are handled in the same service context.
In live commerce, a change in one part meets the user flow of another. So beyond whether each function is complete, it is necessary to confirm that the customer experience still connects after a change.
What this project shows is not the variety of technologies used but the way their relationships were handled together. The messaging that creates customer touchpoints, the payments that process transactions, the cloud that hosts the service, and the QA that confirms changes were connected as one object of operations.
From a service where broadcasts can be watched, to a service that guides customers, carries transactions through, and keeps improving. Company B's build scope covered that whole flow.