Cross-border payments fail when users have to trust too many unfamiliar steps at once.
Sending money across borders is a high-intent action with trust, compliance, and clarity requirements.
The experience had to make sensitive steps feel secure and recoverable while keeping the interaction simple on the surface.
Users needed a faster way to begin and complete money movement without learning another financial interface.
Identity, card, recipient, and transaction steps had to feel secure, legible, and reversible.
The product needed to support sending, requesting, gifting, and account actions without forcing one generic path.
The system had to support future corridors, rails, wallets, and adjacent products.
A messaging-first payment journey backed by transaction architecture.
Guided users through payment actions in a familiar messaging-led channel.
Structured trust checks for sensitive financial actions.
Send, request, gift, card, recipient, and confirmation flows connected into one journey.
Status updates, recovery, and service support embedded into the payment experience.
The surface was conversational, but the operating layer handled regulated payment workflows underneath.
From message initiation to completed money movement.
- 01Begin in a familiar channel
Start the journey through a conversational entry point instead of a standalone financial workflow.
- 02Verify payment readiness
Sequence identity, card, and account checks before exposing transaction actions.
- 03Choose the action
Support send, request, gift, and recipient-linked flows based on user intent.
- 04Confirm and complete
Make amount, recipient, payment method, and next status clear before completion.
- 05Track and recover
Keep status, support, and future actions available in the same operating layer.
The experience looked conversational. Underneath, it behaved like a transaction-grade operating system.
What changed when the workflow became connected.
Users moved between unfamiliar financial screens and support channels.
Users could move through key money movement actions in a guided messaging-led journey.
Identity, card, recipient, and payment steps created trust friction.
Sensitive steps were sequenced with clearer state, confirmation, and recovery paths.
Send, request, gift, and support actions were treated as disconnected tasks.
Payment, recipient, notification, and support workflows became part of one product layer.
Future corridor and wallet expansion risked adding product complexity.
The architecture supported additional corridors, rails, wallets, and adjacent services.
The chatbot could not be a thin interface on fragmented payment systems.
Every message needed to understand where the user was in the transaction lifecycle.
Verification and confirmation had to be designed into the journey, not appended at the end.
Payment questions, status, and recovery needed to live where the user was already acting.
Future corridors and payment services had to fit without rethinking the experience model.
Mantra can make conversational interfaces credible for regulated financial workflows.
The work connected conversation design to identity, payments, support, and operational architecture.
Sensitive user actions were sequenced into guided, recoverable steps.
The system created room for corridor, rail, wallet, and service expansion.
The product story is about operating-layer design, not a messaging widget.
The capabilities behind the build.
Journey design and engineering across onboarding, recipient setup, transaction flows, and support.
Service separation and integration logic for identity, payment, notifications, and support.
Structured transaction and interaction state made future guidance and monitoring possible.
Sensitive payment and identity steps were handled through controlled, auditable workflow design.