# Build an Earn pocket

Add a productive destination for stablecoin balances inside an account your customers already use.

For a fintech or neobank, the opportunity is a familiar account experience with an additional use for a stablecoin balance. A customer chooses an amount, sees it in an Earn pocket, and can follow its value without learning how to operate lending markets.

## The customer journey

| Step | In your product | What your integration must establish |
| --- | --- | --- |
| Discover | An Earn entry beside the existing stablecoin balance | Eligibility, asset, network and rate source |
| Choose | An amount and a clear explanation of the product | Consent, fees, withdrawal mechanics and risk information |
| Confirm | A visible pending state followed by a confirmed position | Signing authority, transaction submission and confirmation |
| Follow | Earn balance, accrued yield and activity | Position attribution, current value and timestamps |
| Return | Withdraw to the customer's available balance | Liquidity checks, transaction state and final balance reconciliation |

## Connect the customer to your account

Create an attributed user through `POST /users` with a partner-scoped key. Store the returned user ID against your internal customer ID. Use the user's linked wallets and partner attribution to connect the reporting records to your product.

The Partner API provides a user record and reporting context. The movement between an available balance and an Earn position must also follow your agreed wallet and settlement design. See [customer attribution](/build/users/).

## Make balance states unambiguous

Show available balance, pending movement and Earn position as distinct states. A request accepted by your backend is not confirmation that assets have reached a vault. Keep pending funds visible until the transaction and account records agree.

Read attributed positions with `GET /partner/user/{id}/positions`, then use the user's ledger to explain changes over time. Avoid labelling a projected annual return as money already earned.

## Build the business case from the same data

`GET /partner/summary` gives the product team an account-level view. `GET /partner/revenue` estimates partner revenue from the current calculation inputs. Start with those inputs and your commercial agreement, rather than a fixed yield headline.

The [partner economics guide](/concepts/revenue/) explains the difference between customer yield, protocol fees and partner revenue.

## A useful pilot

Choose one customer segment, one asset and one network. Test the complete deposit-to-withdrawal journey, the customer's statement and a support case. Before expanding, verify the [launch and operations checklist](/operate/launch/) with the team that will own the feature.