Embedded Business Wallets

Use Turnkey’s embedded wallet infrastructure for internal enterprise operations: treasury management, payroll automation, vendor payments, and organizational spending controls.

Why Turnkey for Embedded Business Wallets?

The same Embedded Wallet Kit that powers consumer applications works equally well for internal business operations: treasury, payroll, vendor payments, and operational funds.

Let Turnkey run your wallet infrastructure for business operations. Define who can sign, what they can sign, and how many approvals are required. Set spending limits and recipient allowlists. Private key material and sensitive operations are protected through Turnkey’s verifiable security architecture.

Use the policy engine to define your approval workflows. No contract deployments or on-chain coordination necessary.

Common use cases

Need	Turnkey solution
Merchant deposit addresses	Instant wallet provisioning with policy-enforced sweeping to omnibus
Contractor and vendor payments	Contact lists with pre-approved addresses and spending limits
Scheduled recurring payments	Scheduled payments to allowlisted recipients without manual signing
Delegated spending	Grant limited payment authority to teams or individuals
Multi-approval workflows	Require 2+ approvers for high-value transactions
Spending controls	Per-transaction limits, asset restrictions, and role-based rules

Core capabilities

Programmable approval requirements: Define how many approvals each transaction type needs. For example, small payments auto-approve, large transfers require multiple signers.

Role-based access control (RBAC): Tag users as “finance-team” or “executive”, then use Turnkey’s policy engine to grant specific permissions to those groups.

Recipient allowlists: Maintain approved vendor and contractor addresses. Payments to known recipients can bypass additional approval steps.

Automated scheduled payments: Backend services sign recurring transactions (payroll, subscriptions) based on policy rules. No manual intervention required.

Spending limits: Enforce per-transaction maximums, asset restrictions, or destination restrictions at the policy level.

Example: Merchant deposit addresses with automated sweeping

Provision deposit addresses instantly for merchants or customers. Enforce that funds can only move to your omnibus wallet, and only approved assets (like USDC) can be transferred.

Architecture:

┌─────────────────────────────────────────────────┐
│  TURNKEY ORGANIZATION                           │
│                                                 │
│  Wallet ──▶ Unique deposit address per merchant  │
│                    │                            │
│                    ▼                            │
│  Policy Engine ──▶ Sweep to omnibus (USDC only) │
│                    │                            │
│                    ▼                            │
│  Omnibus Wallet (consolidated treasury)         │
└─────────────────────────────────────────────────┘

Policy: Restrict transfers to USDC only, omnibus destination only

First, upload the USDC contract ABI as a smart contract interface via the dashboard or API. Then create a policy that references the parsed contract call arguments:

{
  "policyName": "USDC transfers to omnibus only",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.tags.contains('sweep-service'))",
  "condition": "wallet.id == '<WALLET_ID>' && eth.tx.to == '<USDC_CONTRACT_ADDRESS>' && eth.tx.function_name == 'transfer' && eth.tx.contract_call_args['_to'] == '<OMNIBUS_WALLET_ADDRESS>'"
}

All other transfer attempts are implicitly denied. Wrong token? Denied. Wrong destination? Denied. The policy engine enforces your rules at signing time.

Transaction flow:

1. Create a unique merchant address in instantly via API (~100ms)
2. Customer deposits funds to merchant’s unique address
3. Backend sweep service lists balances across all merchant wallets
4. Sweep service signs transfers to omnibus wallet
5. Policy enforces USDC-only, omnibus-only at signing time

Example: Contractor and vendor payments

Maintain a contact list of approved payment recipients. Store each contractor’s preferred wallet address for USDC disbursements.

Set up recipient allowlist policy:

With the USDC ABI uploaded as a smart contract interface, you can restrict payments to approved recipients:

{
  "policyName": "Auto-approve payments to verified vendors",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.tags.contains('accounts-payable'))",
  "condition": "wallet.id == '<WALLET_ID>' && eth.tx.to == '<USDC_CONTRACT_ADDRESS>' && eth.tx.function_name == 'transfer' && eth.tx.contract_call_args['_to'] in ['<VENDOR_1_ADDRESS>', '<VENDOR_2_ADDRESS>', '<CONTRACTOR_ADDRESS>']"
}

Payments to known recipients execute with single approval. Add new vendors by updating the policy. No on-chain changes required.

Example: Scheduled recurring payments

Set up automated payments that execute on a schedule without manual signing. Pay contractors on the last business day of each month for the next 6 months.

1. Configure payment schedule

   Define recurring payments in your application: recipient, amount, frequency, duration.

2. Create backend signing policy

   Allow your backend service to sign transactions to specific recipients up to specified amounts:

   {
     "policyName": "Backend can execute monthly contractor payments",
     "effect": "EFFECT_ALLOW",
     "consensus": "approvers.any(user, user.id == '<BACKEND_API_USER_ID>')",
     "condition": "wallet.id == '<WALLET_ID>' && eth.tx.to == '<USDC_CONTRACT_ADDRESS>' && eth.tx.function_name == 'transfer' && eth.tx.contract_call_args['_to'] in ['<CONTRACTOR_1>', '<CONTRACTOR_2>']"
   }
   
3. Trigger payments on schedule

   Your backend executes payments when due. No manual approval required for pre-authorized recipients and amounts.

Example: Delegated spending authority

Grant limited payment permissions to individuals or teams without giving full wallet access.

Petty cash for operators

{
  "policyName": "Operators can make small purchases",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.tags.contains('operator'))",
  "condition": "wallet.id == '<WALLET_ID>' && activity.action == 'SIGN' && eth.tx.value <= 500000000000000000000"
}

Contractor self-service withdrawals

{
  "policyName": "Contractor can withdraw earned funds to registered address",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<CONTRACTOR_USER_ID>')",
  "condition": "wallet.id == '<WALLET_ID>' && eth.tx.to == '<CONTRACTOR_WALLET_ADDRESS>' && eth.tx.value <= 2000000000000000000000"
}

Department budgets

Assign each department a spending limit. Marketing can spend up to $25k without executive approval:

{
  "policyName": "Marketing team budget authority",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.tags.contains('marketing-team'))",
  "condition": "wallet.id == '<WALLET_ID>' && activity.action == 'SIGN' && eth.tx.value <= 25000000000000000000000"
}

Example: Multi-approval workflows

Require multiple approvers for high-value or sensitive transactions.

Two finance approvers for large payments

{
  "policyName": "Require 2 finance approvers for transactions over $10,000",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.filter(user, user.tags.contains('finance-team')).count() >= 2",
  "condition": "wallet.id == '<WALLET_ID>' && activity.action == 'SIGN' && eth.tx.value > 10000000000000000000000"
}

Executive approval for major transactions

{
  "policyName": "CFO required for transactions over $50,000",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.tags.contains('cfo'))",
  "condition": "wallet.id == '<WALLET_ID>' && activity.action == 'SIGN' && eth.tx.value > 50000000000000000000000"
}

Example: Spending controls

Implement organizational controls beyond simple approval requirements.

Control	Policy approach
Per-transaction limits	Set eth.tx.value ceiling in condition
Recipient restrictions	Allowlist addresses with eth.tx.contract_call_args['_to'] in [...]
Role-based limits	Different consensus rules per spending tier
Asset restrictions	Filter by contract address for token transfers

See Policy Language for the full syntax and Access Control Examples for more patterns.

Trusted by leading businesses

Turnkey’s infrastructure powers enterprise payment operations at scale. See Turnkey Customers for more examples.

Mural Pay: Cross-border stablecoin payments for non-crypto-native organizations.

Metric	Value
Monthly stablecoin payments	5,000+
Transaction volume (12 months)	$200M+
Integration time	3 weeks

Implementation workflow

1. Create your organization

   Sign up for Turnkey and create your parent organization.

2. Create operational wallets

   Create wallets for your business operations: treasury, payroll, vendor payments. See Wallets Concept for HD wallet structure.

3. Define user roles

   Create user tags representing roles in your organization (finance, operations, executive). Add users and assign appropriate tags.

4. Implement policies

   Write policies encoding your approval workflows and spending controls. See Policy Quickstart for setup guidance.

5. Build payment workflows

   Integrate Turnkey’s API to build approval interfaces, payment automation, and operational dashboards. See Transaction Automation for backend signing patterns.

Resources

• Policy Engine Overview: Fundamentals of Turnkey policies
• Access Control Examples: Sample RBAC policies
• Signing Control Examples: Transaction signing policies
• Delegated Access: Backend automation patterns
• Transaction Automation: Building automated signing workflows