Keeping the bill inside the conversation
Shared spending is usually a social problem before it becomes a payment problem. Friends decide where to eat in a group chat, one person pays, and the conversation continues while the receipt disappears into a pocket. Later, somebody has to remember who ordered what, calculate each share, and chase the people who have forgotten.
Ember keeps the discussion with the transaction. A group can talk, attach a shared purchase, review the receipt, claim individual items, and see how the cost is divided. Questions and disagreements stay beside the bill instead of moving into a spreadsheet and several payment requests.
Priority Soft helped define how that product should work, researched the constraints imposed by payment providers and mobile platforms, and built the native iOS application and supporting service layer. The challenge was to make spending feel like part of a familiar group conversation while giving money, identity, and private messages the care they require.
One group, one shared context
At the center of Ember is the group. The same people who exchange messages are the people involved in a purchase, which gives the product a clear answer to a difficult question: who should be able to see and act on this transaction?
A member can create or join a conversation and associate a purchase with it. The group sees the total and the available receipt items in the context of the discussion that led to the spending. There is no need to rebuild the participant list in another tool or explain what an isolated payment request refers to.
Chat and spending share one product model. A transaction can create activity in the conversation, a claim or change can notify the relevant people, and read states show whether an update has been seen.
This connection is what makes Ember distinct. Messaging does not sit beside a separate finance tab. It provides the social context required to settle a real bill, especially when the split is more complicated than dividing the total by the number of people present.
Splitting the items people ordered
Equal splits work for some purchases and fail badly for others. One person may have ordered a single item while somebody else covered several. A group may share one part of the bill but not the rest. Tips, adjustments, or an unclear receipt can make the final numbers harder to agree on.
Ember allows participants to review the purchase at item level and claim the things that belong to them. Where item claims are not the right fit, the group can use a custom split. Each person's part remains connected to the original total, so the group can see what has been assigned and what still needs attention.
The split is collaborative. Participants can accept their share, decline it when something is wrong, and discuss the issue in the same conversation. The interface allows for receipts that need correction.
That room for correction matters. Money between friends is sensitive even when the amounts are small. A product that silently assigns a debt may create more friction than it removes. Ember makes the proposed division visible and gives the people involved a clear way to resolve it.
Status that answers the awkward questions
Shared expenses become uncomfortable when nobody knows what is finished. Has everyone claimed their items? Did one person reject the split? Is the bill waiting for somebody, or has it already been settled?
Transaction states answer those questions without requiring the group to reread the chat. Individual shares have their own status, while the overall bill reflects group progress.
Notifications cover new claims and actions that need review. They open the relevant transaction and conversation, not a generic activity screen.
The product preserves the discussion around a change without treating chat as the system of record. Messages explain why people made a decision; structured status records what the group agreed. That distinction keeps the interface human and the financial state understandable.
Researching payment feasibility before promising the experience
Products that touch cards, bank accounts, and contactless payments operate inside constraints set by financial providers and mobile platforms. A compelling design is not enough if the required transaction access or movement of funds cannot be supported responsibly.
Feasibility work covered card issuing, bank connections, transaction retrieval, and contactless payment before the product flow was fixed. It separated the experience Ember could own from capabilities that depend on provider approval.
The team also kept individual responsibility clear. Ember was not designed around friends sharing a joint credit facility. The product associates each person's part with the group purchase while avoiding claims that it provides a bank account or regulated financial service.
This is an important part of our work even though it is mostly invisible in the interface. We challenged the product concept where provider constraints mattered, then built the group, claim, and status model around behavior the system could support. Ember's public story remains a shared spending and communication product, not a promise of banking capabilities it has not established.
Treating private conversation as private
Ember holds two kinds of sensitive context at once: what people say and how they divide a purchase. Security could not be added after the chat experience was already built.
Established Signal protocol components support encrypted conversations and key exchange between participants. Realtime delivery keeps messages current, while read receipts and channel preferences provide expected chat behavior.
Media and receipt images use controlled cloud storage. Authentication, group membership, and access rules determine who can retrieve information from a conversation.
This case study does not expose encryption material, private messages, contact relationships, receipt contents, or transaction records. Group context controls access, and security sits in the messaging architecture.
A native iOS experience for chat and spending
Ember is built as a native iOS application in Swift. That choice gives the product direct access to the interaction patterns people already understand on an iPhone and supports the responsive behavior required by realtime messaging.
The mobile experience keeps chat familiar while transaction cards and claim controls introduce shared spending. Users can move from a message to a receipt, from an item to their share, and back to the discussion without losing the group.
The application has the supporting views and states required around that loop: onboarding, contacts, conversations, transaction summaries, receipt review, claims, notifications, and account controls. The exact interface changes with the task, but the visual language stays consistent enough that financial actions do not feel like a different application opened inside the chat.
Native development also made it possible to handle system notifications, secure local behavior, and rich conversation interactions in a way that feels appropriate to the platform.
A service foundation shared by messages and transactions
The service layer uses NestJS and TypeScript with PostgreSQL for structured product data. WebSockets and Redis support live conversation updates, while managed object storage handles private media. Messaging and transaction services share identity and group membership without mixing their responsibilities.
Chat manages channels, messages, delivery, and read state. The spending domain manages purchases, participant claims, individual shares, and progress. They connect through the group and through transaction events shown in the conversation.
Service tests keep changes in one domain from breaking the other. A transaction can move through its states while the conversation remains available, and message delivery does not decide the financial outcome of a bill.
This high level structure gives Ember room to refine payment integrations later without rebuilding its social foundation. The group and settlement model already describe what the user is trying to accomplish.
What Priority Soft brought to Ember
We began with responsibility for a purchase, agreement on item claims, disputed shares, and the capabilities that depend on financial partners. Those decisions came before wiring a payment provider into chat.
We translated those decisions into a native product where private conversation and structured transaction status share one group. Security, realtime behavior, receipt media, notifications, and item-level settlement use that same context.
That work gave the client something more useful than a technical demo. Ember has a product model capable of representing the messy social reality of a shared bill while keeping its financial claims appropriately narrow.
The outcome
Ember gained a working foundation for settling shared spending where the conversation already happens. A group can attach a purchase, review and claim items, agree or challenge individual shares, and follow the bill toward resolution without moving between several disconnected tools.
Priority Soft addressed provider feasibility, private messaging, participant responsibility, and every state between a new receipt and a resolved split. Each participant can see the transaction context and what they are being asked to accept.