Multi-Card Capture

Overview

Multi-Card Capture keeps every physical card together from camera to Vault. Tap the center camera action, choose Add cards to Vault, then add one card or a batch. Price Check remains separate and never creates inventory unless you explicitly choose Add to Vault from its result.

How It Works

Multi-Card Capture is a four-phase flow:

Phase 1: Capture

Choose Take photos, Choose photos, or resume unfinished work. Capture always follows this order:

1. Card 1 — Front
2. Card 1 — Back
3. Review, retake, or confirm Card 1
4. Card 2 — Front
5. Card 2 — Back
6. Continue for all cards…

A durable card record owns explicit front and back slots. The header always shows the current card number, expected side, completed count, finish action, and a safe close control. Closing keeps saved work available under Resume; discarding it requires confirmation.

The installed app and touch-first mobile browsers open the phone's rear still camera for each side. That small extra tap preserves the camera's full still detail instead of uploading a grainy frame from a WebView video preview. Desktop browsers keep the continuous manual-shutter viewfinder.

Phase 2: Confirm Each Card

After every back, the app shows that card's front and back together. You can:

• Retake Front / Retake Back — re-capture a single side
• Remove — delete the card without shifting any other pair
• Confirm — lock the pair and continue to the next card

After upload, the batch workspace's Check front/back pairing action validates the complete session—not only the first page—using explicit side labels and front/back identity stems. A mismatch shows both candidate images and requires visual confirmation before a remap is staged. Correctly combined pairs are checked without rewriting them.

Because sides belong to an explicit card record, a retake, removal, reorder, background interruption, or relaunch cannot shift later pairs.

Phase 3: Final Review

Review every pair before submission. Retake either side, remove or reorder a card, add another, or submit the batch. A card with only one side cannot be submitted.

Phase 4: Upload and Processing

Submission uploads the exact reviewed pairs under one stable session ID. The capture screen shows item and byte transfer progress. As soon as the server durably accepts the batch, RocketVault opens its processing page; recognition continues without blocking the camera flow.

Successful cards stay successful when another card fails. Retry only the card that needs attention. A card is marked Complete only after its tenant-owned inventory record is committed and retrievable through the Vault. Use View in Vault to open the exact result, including the existing card updated by a safe duplicate merge.

Tips for Best Results

• Good lighting — use natural light or a well-lit area. Avoid harsh shadows and direct glare on glossy cards.
• Contrasting background — place cards on a surface that contrasts with the card edges (dark cards on light surface, and vice versa).
• Steady hand — hold your phone steady or prop cards against a flat surface. Blurry photos reduce identification accuracy.
• Card-by-card order — always finish and confirm one front/back pair before moving to the next card.
• One card per photo — each photo should contain exactly one card. Don't group multiple cards in a single frame.

RocketVault checks image quality in the gallery, desktop live camera, mobile still camera, and retake paths. Borderline images stay visible with a warning. When the quality gate is in blocking mode, an unusable photo must be retaken before it can be saved to the reviewed Vault batch.

Troubleshooting

Photos aren't pairing correctly Retake the affected side from that card's review. Other cards are never reconstructed from filename or capture time, so the correction cannot shift their images.

Odd number of photos If you have an unpaired photo, go back to capture its matching side, use it as a front and tap Capture Back, or remove it. Process remains disabled until every card has a complete pair.

Upload failed Captured photos remain available for retry or resume. The installed app retries temporary native connection failures, checks the bytes sent, and asks the server to verify every object before processing. If the error persists, confirm the app has a connection and try again; adaptive batching already reduces large sessions automatically.