In this article
Create a directional inventory that separates a linked instrument from an available way to move money.
A saved bank or card label can look like a universal payment option. In a platform integration, that shortcut creates confusing screens and brittle routing rules. Build an inventory that answers three different questions: what instrument is linked, which direction the money should move, and which method is actually available for this participant and action.
Use the provider’s distinction carefully
Moov’s payment-methods guide distinguishes funding sources from payment methods and capabilities. Methods describe how funds move, and many are directional. Additional verification can be required for a particular method. A source appearing in a profile therefore should not be treated as evidence that every imagined operation is ready.
The useful editorial pattern is to model instruments and operations separately. An instrument record describes the linked object using an opaque identifier and an approved display label. An operation record describes the contemplated movement: source participant, destination participant, amount, currency, and purpose. Eligibility connects these records at decision time. This arrangement makes it easier to explain why an instrument can appear in a profile but be absent from one payment menu.
Keep the inventory small and purposeful
For a design review, you need identifiers, environment, instrument category, ownership association, verification observation, available method identifiers, and the time those observations were collected. You do not need full account numbers, card numbers, security codes, or authentication material. Use fictional identifiers when the review is educational. Real operational records belong in an authorized system with appropriate access controls.
Add an “unknown” condition rather than coercing every record into available or unavailable. A failed retrieval, stale cache, or incomplete response is different from a confirmed restriction. The interface should offer a safe refresh or support path when evidence is missing. It should not silently choose a different instrument because the intended one could not be evaluated.
Fictional worked example: the same bank, different jobs
In a fictional scheduling platform, Birch Lessons wants to collect a $120 booking charge and later pay a teacher $80. The initial product sketch gives both screens a single choice labeled “bank.” During review, the team notices that collection and payout are different operations with different participants and prerequisites.
The revised worksheet names the payer’s instrument for the collection and the teacher’s instrument for the payout. Each row has a direction and an independently observed eligible method. If the collection row lacks usable evidence, the team does not infer readiness from the payout row. The $120 and $80 figures are examples, not pricing or a statement about any actual Moov account.
Birch also removes a misleading message that said “Bank connected, all set.” Its replacement confirms the completed linking step and separately describes the next required step for the selected action. That small copy change prevents a profile milestone from becoming an accidental promise that a payment will succeed.
Refresh at meaningful boundaries
Decide when the application needs fresh eligibility information: entering a payment flow, changing its amount, selecting another recipient, or returning after an instrument update. These are design checkpoints, not a prescribed polling schedule. The right refresh policy depends on the current API contract, performance needs, and the consequence of acting on stale information.
Do not store one global “preferred method” value and reuse it across unrelated participants. A preference should have an owner, a purpose, and a fallback policy. If a saved preference is no longer eligible, explain the situation and request another choice when the change would affect the user’s expectations. Preserve a record of the actual method used for each operation, rather than relying on the profile’s present-day preference.
Inventory checklist
- Separate instrument identifiers from payment-method identifiers.
- Record source and destination roles for every proposed action.
- Distinguish missing evidence from confirmed unavailability.
- Keep sensitive instrument data outside planning documents.
- Define refresh points and stale-data behavior.
- Check actual account limits rather than relying on a public maximum.
- Record the final selected method with the payment intent.
Know the boundary
This inventory is a design aid, not an eligibility engine. Moov’s current account-specific responses, requirements, and approved integration determine what is usable. Public method lists are not a guarantee that your business, participant, amount, or instrument qualifies. A useful inventory makes uncertainty explicit so that the product can ask the right question before money movement begins.