Lifecycle
Receiving details change state
Your product needs to handle requested, active, suspended, and closed receiving details without losing the customer context.
Virtual Account Integrations
Build around the full receiving flow
Create and manage receiving details, read deposit status, and carry the right references into support and finance. Gruv maps the approved API contract and access to your account.
Account-scoped operationsIdempotency keysDeposit history
Receiving details
Account-scoped lifecycle
CreateReceiving details
Read & listCurrent state
CloseLifecycle update
Deposit visibility
Status and references
Credited
Held
Returned
Account scopedRetry key on changes
The first API call is only the beginning
A useful integration follows the receiving details and the money that arrives against them—not just the create request.
Retries
Writes need a stable request key
Create and close requests require an idempotency key, so repeated attempts can carry the same request identity.
Deposits
Incoming money has its own status
Plan for pending, credited, held, returned, and unmatched deposits—and decide what the user sees in each case.
References
Support and finance need the thread
Keep the receiving-detail, provider transaction, sender, and journal references your teams need to explain a deposit.
Receiving lifecycle
An integration shaped around the money lifecycle
Build around the actions and states your customer experiences, then carry the same references into support and finance.
Create, read, list, and close
Use the account-scoped operations approved for your setup to manage receiving details through their lifecycle.
Read deposit history
List deposits for receiving details or read one deposit when support needs the complete status and references.
Preserve useful references
Carry provider transaction, sender, and journal references into the systems that explain and reconcile incoming money.
Give exceptions an owner
Decide who responds when receiving details are suspended or a deposit is held, returned, or unmatched.
Capabilities
The details your product should carry
Receiving-detail identity and state
Keep the account scope, receiving-detail ID, currency, provider reference, and current status together.
Deposit status
Show whether incoming money is pending, credited, held, returned, or unmatched.
Sender and provider references
Keep the identifiers support needs when a customer asks what happened.
Finance reference
Carry the journal or downstream reference used to reconcile a credited deposit.
How it works
From customer flow to working integration
More in Virtual Accounts
Explore more in Virtual Accounts
Frequently Asked Questions
Which virtual-account operations are implemented?+
Gruv has account-scoped create, list, read, and close operations for receiving details, plus list and read operations for deposits. Production access, markets, currencies, and schemas are confirmed for your account.
How should create or close retries work?+
Create and close requests require an idempotency key. Reuse the same key when retrying the same intended change, following the production contract provided for your account.
How is API access set up?+
The public site does not publish production endpoints, authentication instructions, SDKs, OpenAPI downloads, or sandbox credentials. Gruv confirms the approved contract, credentials, environment, and availability for your account.
Can virtual-account changes trigger webhooks?+
Customer-facing virtual-account event delivery is not published as a standard capability. If your design needs push updates, ask Gruv to confirm the event types, signing, retry, replay, and environment available to your account. Otherwise plan around the available status reads.
Next step
See where Gruv fits
Tell us what you are trying to do, where it needs to work, and how your team handles it today.
Contact the team