Last week, 1Z Entertainment, the management group behind SB19, used one of our no-code solutions, PayRex Pages, to sell global fan packages (GFP) to their international audience for their upcoming concert.
For us, this wasn't just a global fan package sale. It was the first real stress test of our PayRex Pages storefront template under high-traffic, cross-border conditions. It validated parts of our thesis and surfaced areas where we still have work to do. We think both are worth sharing.
Our core product is our public API. It’s designed to be easy to integrate, and we are proud of that. But there is a class of merchant, one with a business and a deadline, who shouldn't need to write code to start getting paid.
PayRex Pages is our answer to that: a no-code payment solution that lets businesses create a payment page with custom fields, configurable templates, and the same underlying infrastructure as our API. The goal is time-to-revenue, not time-to-integration.
We spoke to 1Z due to card declines, particularly for international fans processed through another gateway.
This is a more serious problem than it sounds. A failed payment is not just a lost transaction. It affects:
We worked closely with our acquiring bank and internal risk team to develop a risk assessment framework tailored to the transaction profile. During the sale, we saw improved completion rates compared to 1Z's previous gateway. Some fans publicly posted about successful payments, which is the kind of signal that's hard to manufacture.
Payment acceptance isn't a feature you add later. It's a foundation. If checkout doesn't reliably complete transactions, everything downstream breaks.
1Z had a specific workflow requirement. Before finalizing a global fan package, they needed to:
The naive implementation, capture first, validate second, creates a refund problem. Refunds introduce processing fees that aren't fully reversible, operational overhead, and reconciliation noise. None of that is acceptable at scale.
We used our card hold-then-capture capability to solve this at the architecture level:
No refund is ever issued. No fee is incurred on invalid transactions. The process is cleaner because the design is cleaner. The goal was never to process refunds efficiently; it was to build a flow that doesn't generate them.
1Z also used PayRex Pages' custom fields feature to collect guest information directly at checkout.
The alternative, an external form matched manually to payment records, is a coordination tax. Two systems, two sources of truth, and someone spending time reconciling them.
By embedding structured data collection into the payment itself, each transaction became both a financial event and a validated data record. Downstream operations were simplified because the upstream design was intentional.
We think about payments as workflow anchors. When integrated correctly, they reduce coordination costs throughout the entire order lifecycle, not just at checkout.
One of the clearest operational wins for 1Z was the speed of reconciliation. With their previous payment gateway, closing out a package sale could take a month.
With PayRex, the payment data was structured, the validation was embedded in the payment lifecycle, and settlement visibility was immediate. 1Z completed the daily sales reconciliation by the end of the day.
Faster reconciliation isn't cosmetic. It directly compresses the feedback loop between sales activity and financial reporting, which matters for cash visibility and operational planning.
We encountered degraded performance during peak traffic windows. This was PayRex Pages' debut under significant concurrency, and high-demand launches revealed real constraints: traffic-handling limits, burst-capacity assumptions, and frontend rendering under load.
We're not going to dress this up. The system held, but not as cleanly as we'd like.
We have already identified specific improvements around traffic distribution and storefront optimization. Infrastructure maturity is measured under stress, not in quiet periods. This event gave us real numbers to engineer against.
This sale reinforced something we care about deeply: payment infrastructure should improve acceptance, reduce waste, and simplify operations, simultaneously, not sequentially.
In this engagement, we:
That's not payment processing. That's operational design.
PayRex Pages was built to make that available without requiring engineering resources to deploy it. This was its first meaningful test.
We're refining it. We're scaling it. And we're building toward higher concurrency and broader use cases.
Feel free to reach out to us for any inquiries or support you may need. We're excited to connect with you and provide the information and support you need to make informed decisions for your business. Let's embark on a journey of innovation and success together.
