Most print companies design their product around the PSPs they're currently connected to. This is backwards. You should design as if you have infinite PSP optionality, then layer reality on top.

Why optionality matters

Optionality is the ability to make choices later, when you know more. In print, that means:

  • You can add a new provider without redesigning your platform
  • You can switch providers without changing your API
  • You can test a new provider's economics without committing to integration
  • You can negotiate better rates because switching isn't expensive

Companies without optionality are locked in. They've built their routing logic around Provider A's quirks. Their product exposes Provider A's capabilities and limitations directly. Switching is a full rewrite.

Companies with optionality treat PSPs as fungible. Customers don't know or care which provider fulfills their order. The platform decides based on available options at order time.

One is a commodity business with limited leverage. The other is a platform business with pricing power.

Build at the abstraction level

The key to optionality is building at the abstraction level, not the provider level.

Don't ask: "What does Provider A support?"

Ask: "What core capabilities do all providers need to support?"

For example, don't say "we support glossy finish because Provider A has it." Say "we support finish types, and today we offer glossy, matte, and silk because our connected providers collectively support them." When you add Provider B who supports linen, that capability appears automatically.

This is subtle but critical. It means your product capability set is the union of what your providers support, not what one provider supports. And it means adding a new provider with new capabilities extends your product without redesign.

Design your product at the abstraction level. Implementation details are which providers offer that abstraction.

Product design implications

PSP optionality changes how you design product experiences:

  • Availability: Don't show "Provider A is unavailable." Show "glossy finish is unavailable for 2-day shipping." The customer doesn't know or care which provider offers which combination.
  • Pricing: Don't show "Provider A costs 20% more." Show transparent pricing that's already aggregated across providers. Your system made the routing decision; customers see the result.
  • SLA: Don't promise "Provider A guarantees 5-day delivery." Promise "we guarantee 5-day delivery to California from one of our connected fulfillment partners." Your platform made that work.
  • Customization: Don't let customers "pick a provider." Let them pick outcomes (fastest, cheapest, best-quality) and your platform routes to achieve that outcome.

This is more work upfront. But it decouples your product from your providers. You can change providers without your customers noticing.

The pricing model problem

This is where it gets hard. Providers have different pricing models:

  • Provider A charges per unit
  • Provider B charges per unit but with volume discounts
  • Provider C charges flat-rate per order
  • Provider D uses dynamic surge pricing

You can't expose all of this to customers. You need a normalized pricing model that works across all providers.

Options:

  1. Markup fixed margin: Charge customers a fixed markup on cost-of-goods. Simple, but margin erodes if provider costs change.
  2. Dynamic pricing: Update customer prices when provider costs change. Complex operationally, customers hate it.
  3. Tiered pricing: Bucket products into price tiers. Absorb provider variance within the tier. Most sustainable.

The point is: design your pricing to be provider-agnostic. Make it possible to swap providers without changing your pricing structure. That's optionality.

How Oruve handles this

Oruve's platform is built specifically to enable PSP optionality. The canonical product and spec model abstracts away provider-specific quirks. Routing decides which provider fulfills each order, based on your business rules. Pricing sits on top of the canonical model, not the provider model.

This means:

  • You can add a new provider in days, not months. Their capabilities are merged into the platform automatically.
  • Your product doesn't change. New provider capabilities appear as options, but your core offering stays the same.
  • You can negotiate with providers knowing you can switch quickly. That leverage translates to 10-20% better pricing.
  • You can test new business models (dynamic routing, provider arbitrage, geographic optimization) without changing your customer API.

Optionality isn't free. It requires abstraction, investment in the platform layer, and discipline about not leaking provider-specific logic into product.

But the payoff is worth it. The companies with optionality are the ones that scale.