PayPhone Proxy: Thinking Outside the Box

PAYPHONE // STORE_ID // THINK_OUTSIDE_THE_BOX

I was not trying to build a payment gateway. I just wanted to keep building.

With development agents, many ideas that used to stay in my head can now become working projects. None of them has been successful yet, at least not commercially. That does not make me want to stop. When an idea appears, I want to open it, build it, and find out later whether it has a future.

The problem was that PayPhone Developer allowed me to create a maximum of three applications.

I did not need more applications because I already had sales

I needed more room because my way of working is turning ideas into real experiments.

My ecosystem contains projects from completely different categories:

• PachaPixel, focused on digitally preserving Ecuadorian archaeological heritage through drones, photogrammetry, and 3D models.[7]
• nexOS, a commercial operating system for Ecuadorian small businesses that connects invoicing, CRM, communication channels, payments, and automation.[8]
• Lineage2.tuxevil.com, a competitive Lineage 2 server built around PvP, no grinding, and no pay-to-win.[9]
• LeadPulse, a B2B commercial-intelligence and prospecting platform for Ecuador.[10]
• PawPaw, a persistent-identity platform for pets, still in testing.
• Juzgado de lo Absurdo, a multi-user WhatsApp game that turns everyday conflicts into interactive comedy trials, also still in testing.

Four projects are deployed and integrated in production environments, although they are still waiting for their first transactions. The other two remain in testing. I was not operating six mature businesses. I was trying not to close the opportunity funnel before knowing which project might find its place.

PayPhone looked practical to me. Within minutes, I could have an account ready to accept payments from my applications. Deuna, on the other hand, presents itself as a platform for connecting multiple providers, fraud tools, and payment methods through a single integration.[11] My current experience has been different: I had spent approximately two weeks trying to get API access without an answer yet. I am not using that experience to claim that one platform is universally better than the other. It is simply the difference between an integration I could start quickly and another one I was still waiting for.

The limit arrived before the market did

I contacted PayPhone to request more applications. I followed the process, explained that I had several personal projects, provided the domains, and sent the documentation they requested.

The answer was no: I did not yet have enough transaction history to justify the increase. This point comes from my experience with the account, not from PayPhone’s public documentation.

That made sense from the provider’s point of view. I was asking for additional capacity for projects that had not demonstrated volume yet. But it also created a practical contradiction: because I am building and testing new projects, I cannot yet show the history that would justify being allowed to build them.

I did not need a solution for millions of payments. I needed a solution that would keep me from being limited to three experiments.

Changing the axis: application, token, and store

While looking at how PayPhone worked, I realized that the application token was not the only important dimension.

The token is still critical: it is the credential the server uses to talk to PayPhone, and it must not be distributed across projects or exposed to the browser. But in the buyer-facing experience, the StoreID had a different kind of weight. The store name and image PayPhone displayed before payment changed according to the selected StoreID.

That was the opening: one testing application and one production application could centralize the payment flow for several of my projects, while each project remained distinguishable through its store.

I already had six StoreID values and, so far, I had not found an equivalent limit. That is an observation from my own tests, not a claim that PayPhone supports an unlimited number of stores. What mattered was that each identifier displayed the correct identity to the final user.

I started implementing the proxy at that exact moment. The visual verification of the store names and images came later, as confirmation that the direction was right.

I did not bypass PayPhone’s limit

This needs to be explicit: payphone-proxy does not create additional applications, invent permissions, or attempt to bypass PayPhone’s rules.

I use the applications I already have, the authorized StoreID values, and PayPhone’s official Button flow. The documentation distinguishes WEB applications used for Button from API applications used by other products, and I did not assume that a WEB credential automatically enabled the entire catalog.[4][5][6]

The proxy does not replace PayPhone either. It is a layer around the provider. I changed the architecture around the platform, not the platform’s capabilities.

A private API to stop repeating the integration

The project and store configuration is small: it lives in environment variables. The useful part is the internal logic.

The consumer projects call my own API. The proxy authenticates the project, selects the store alias, prepares the payment with PayPhone, and returns a checkout URL. The central checkout is served from the registered WEB domain. PayPhone then returns to the proxy, which confirms the transaction and validates that the identifiers, amount, currency, and store match the original operation.[2][3]

The project began with that private API. I did not want every application to know the PayPhone token or carry its own version of the prepare, checkout, return, and confirmation flow.

The result is not a plug-and-play dependency. Each project needed an adaptation to speak to the new API. But it was not a complicated migration either: remove the direct credentials, replace the PayPhone client with the proxy client, and verify the flow.

The actual architecture of my projects

The separation ended up like this:

Project	Status	Integration
PachaPixel	Production, waiting for first transactions	Shared payphone-proxy
Lineage2.tuxevil.com	Production, waiting for first transactions	Shared payphone-proxy
LeadPulse	Production, waiting for first transactions	Shared payphone-proxy
nexOS	Production, waiting for first transactions	Own proxy for tenant-specific tokens
PawPaw	Testing	Not yet a production payment integration
Juzgado de lo Absurdo	Testing	Not yet a production payment integration

nexOS is the important exception. I do not treat it as another payphone-proxy consumer because each tenant may have its own PayPhone tokens and credentials. To keep that independence, I used the third application available in my Developer panel and kept a separate proxy.

That also defines the project’s real scope. payphone-proxy is not trying to be a universal gateway or solve payments for unrelated merchants. It solves one concrete case: several personal projects that charge the same merchant and can be separated through their configured stores.

The immediate benefit: no more copying secrets

The practical benefit appeared before any real transaction.

I stopped copying and pasting PayPhone tokens into every project. The credentials became centralized. Payment logic, idempotency, checkout, callback, and state handling now live in one place. The browser never receives the provider token, and the projects only know their own internal key.[2][3]

The three common consumers are already deployed in production. They are still waiting for their first transactions, so I am not going to invent sales metrics or present this as a system tested at scale. What I can say is that the integration is in place, the environments are separated, and the flow tests worked for the case I needed.

So far, I have not found a functional limitation in payphone-proxy for that use case either. That does not make the project universal. It means that, within my current needs, the solution is doing exactly what I expected.

Why I opened it

I am getting closer to the open source philosophy every day.

I do not see a secret competitive advantage in this proxy. I also do not think it is particularly hard to reproduce. If someone needs to solve the same problem, I would rather share an implementation that already works than watch everyone build their own clone from scratch.

Besides, I have plenty of forks of other people’s projects myself. Much of what we build exists because someone chose to publish a tool instead of keeping it private. Opening payphone-proxy is a small return of that same logic.

I built it to solve my problem. I maintain it and decide its direction. But if it helps someone else, they can use it, open an issue, or propose a pull request.

The repository is published under the MIT license and documents the flow, configuration, security, and known design boundaries.[1][2]

Thinking outside the box

PayPhone gave me a three-application limit. I could not increase it because I did not yet have transaction history. The answer was not to keep arguing forever or find a way to deceive the provider.

The answer was to look at the problem from another angle.

I did not need a new application for every idea. I needed a shared layer for projects that used the same merchant, and a way to distinguish them without distributing secrets. The StoreID already existed. The private API and proxy were the missing structure around it.

This is not magic. It is not a revolutionary architecture. It is a simple solution that appeared once I stopped accepting that the application limit also had to become the limit of my projects.

Curiosity needs infrastructure too. And when a personal solution can help someone else, I do not see much point in hiding it.

Sources

[1] https://github.com/tuxevil/payphone-proxy — tuxevil/payphone-proxy [2] https://raw.githubusercontent.com/tuxevil/payphone-proxy/main/README.md — PayPhone Proxy README [3] https://raw.githubusercontent.com/tuxevil/payphone-proxy/main/docs/api.md — PayPhone Proxy HTTP API [4] https://raw.githubusercontent.com/tuxevil/payphone-proxy/main/docs/payphone-official-research.md — PayPhone official research included in the project [5] https://docs.payphone.app/configuracion-de-ambiente-y-credenciales — PayPhone configuration and credentials [6] https://docs.payphone.app/boton-de-pago — PayPhone Button [7] https://pachapixel.ec — PachaPixel [8] https://nexos.ec — nexOS [9] https://lineage2.tuxevil.com — Lineage 2 Battle Tournament [10] https://leadpulse.tuxevil.com — LeadPulse [11] https://deuna.com — DEUNA