A developer tests an order import, leaves a sample record in the database, and later opens the shipping queue. The sample looks ready to ship. How do you keep that record from becoming a real purchase?

For crypto shipping labels, put the test/live boundary around the shipment record, the operator’s purchase decision, and the resulting files. A colored banner helps, but the workflow needs stronger controls.

This walkthrough designs those controls for a small shop’s own order-management application. Bitcoin Shipping Labels sells USPS, UPS, FedEx, DHL Express and Canada Post labels, with 100+ cryptocurrencies accepted through NOWPayments. Keep your local testing workflow separate from the live label-buying step.

1. Give every shipment an explicit operating mode

Start with a required field on your local shipment record: test or live.

Set it when the record is created. Preserve it through imports, edits, queue selection, exports and file storage. Treat a missing value as a reason to stop processing.

A useful local record includes:

Field Purpose
Shipment reference Identifies the parcel within your application
Operating mode Separates test records from live work
Order source Shows where the record originated
Package revision Identifies the current packing specification
Address review state Records whether the destination needs attention
Purchase eligibility Controls whether the record can enter the buying queue
Label file reference Connects an acquired PDF to the shipment

Make mode changes deliberate. To turn a test scenario into a real shipment, create a new live record from the actual order and review its details. Keep the original fixture in the test dataset.

That separation gives you a clean history: a fixture remains a fixture, even after someone copies its packing assumptions.

2. Build fixtures around decisions, not realistic identities

Synthetic orders should exercise specific branches of your application. They don’t need copied customer names, addresses or wallet records.

Create a small fixture set with a clear purpose for each entry:

  • Missing unit detail: checks that an unresolved address issue blocks purchase eligibility.
  • Incomplete package measurements: checks that the record stays out of rate review.
  • Changed packing specification: checks that an earlier rate selection receives another review.
  • International parcel: checks that customs information is required.
  • Missing label file: checks that the application doesn’t mark a shipment ready to print.
  • Mixed-mode selection: checks that a test record prevents a batch from reaching the purchase queue.

Use obvious fixture names such as TEST-INTERNATIONAL-MISSING-CUSTOMS. Keep synthetic address values inside local tests. For a real shipment, use the recipient information supplied for that order.

Write the expected outcome beside each fixture. “Needs address review” is more useful than “address test,” because it tells the next developer what a passing result looks like.

3. Separate local checks from rate research

Your application can check that required fields exist before anyone opens a rate tool. Require package measurements and their units, a destination, and the packing revision being reviewed.

Next, distinguish two activities:

  1. Testing application behavior: use local sample results to exercise sorting, selection and error handling.
  2. Researching a live shipment: use the actual packed parcel’s details to review shipping options.

Use the shipping rate calculator for the second activity. Keep its live research separate from your test fixtures.

For local tests, sample rate values should carry an unmistakable TEST DATA label. Exclude those values from postage budgets, sales reports and purchase summaries. Their purpose is to test your interface’s behavior, such as selecting one option from a list.

Record the package revision alongside a live rate review. If an operator later changes the box or measurements, route that shipment back through review before purchase.

4. Test address review as a decision point

Address suggestions help catch apartment and unit mistakes. Design your local workflow so a suggestion prompts a review rather than silently overwriting the order.

Keep three pieces of information together:

  • The address supplied with the order.
  • The proposed correction or unresolved issue.
  • The reviewed shipping address selected for the parcel.

Your fixture should test what happens when review is incomplete. Does the shipment remain outside the purchase queue? Can another operator see what needs attention? Does accepting an edit update the reviewed address while preserving the original order data?

Use a simple acceptance rule: an unresolved destination review blocks purchase eligibility.

For international test cases, add a separate customs-information check. International labels need customs information, so an address-only check leaves a gap in the preflight process.

5. Put a second gate immediately before purchase

Filtering the queue is the first defense. Add another check when the operator prepares to buy the label.

Display a compact purchase summary containing:

  • Live shipment reference.
  • Reviewed destination.
  • Current package revision and measurements.
  • Selected carrier and service.
  • Customs review state, where applicable.

Require the application to recheck that the record is live and eligible at this point. Run the same check for every record in a batch. If a selection contains a test record, stop that selection and identify the offending entry.

Keep payment details outside the fixture library. Bitcoin Shipping Labels accepts crypto through NOWPayments; a local test case can simply model your application’s own states, such as awaiting purchase and label file attached.

Assigning a sample state should never move a record into the live fulfillment queue. Test that boundary directly.

6. Keep test print artifacts away from live labels

Bitcoin Shipping Labels provides labels as 4×6 PDFs. Build your local file handling around that format, with separate locations for test artifacts and purchased labels.

For layout testing, create a plain 4×6 page marked TEST — DO NOT SHIP. Use it to check page orientation, print selection and file routing. Keep customer addresses and tracking information out of the fixture.

Organize stored files by both mode and shipment reference. For example, a test artifact belongs under a test directory, while an acquired label belongs with its live shipment record.

Before releasing a file to your print queue, check:

  1. The shipment is live.
  2. The attached file belongs to that shipment.
  3. The file reference points to the live storage location.
  4. The packing station can identify which parcel receives it.

Keep the test print destination visibly distinct from the live packing workflow. A conspicuous test page is easier to catch than a realistic imitation label.

7. Turn the boundary into a release checklist

Add a short checklist to the GitHub pull request template for changes affecting shipment imports, queues or file handling:

  • Missing operating mode stops processing.
  • Test shipments cannot enter the live purchase queue.
  • Mixed-mode batches are blocked before purchase.
  • Address and customs review gates behave as expected.
  • Package edits trigger another rate review.
  • Test files stay outside live label storage and printing.

Run these checks whenever you change the relevant workflow, rather than relying on a one-time setup.

For the wider packing and purchasing process, see the small-business guide to shipping with crypto. Keep this technical checklist beside your application’s shipping documentation: its job is narrower and concrete—every fixture stays in testing, and every purchase starts from a reviewed live parcel.

Originally published on Bitcoin Shipping Labels - Pay for shipping with cryptocurrency.