![\"\"](\"https:\/\/gtechbooster.com\/media\/2023\/01\/26001.jpeg\")
<\/a><\/div><\/div>None of these changes happened in isolation. They are the visible surface of a deliberate, staged transition that Paystack is managing carefully, one that will eventually move the entire platform and every integration built on it to a new version. The approach is gradual by design. But gradual does not mean unhurried, and developers who are not paying attention risk waking up to broken integrations.<\/p>\n\n\n\n
The context: a platform that has outgrown its foundation<\/h2>\n\n\n\n
Paystack launched in 2016 as a simpler, faster alternative to Nigeria’s existing online payment processors. Over the following decade it expanded across multiple African markets, added payment channels including mobile money, bank transfer, USSD, and Apple Pay, and layered on commerce tools, identity verification, recurring billing, terminal payments, and financial operations for businesses of all sizes. Over 200,000 businesses now process payments through its infrastructure.
The developer platform that supports all of this was built incrementally, each new feature added to an existing foundation that was designed for a much simpler product. A decade of additions without structural revision creates technical debt, inconsistency in API design, and documentation that has grown organically rather than coherently. Version 2 is Paystack’s answer to that accumulated complexity.<\/p>\n\n\n\n
What version 2 actually means<\/h2>\n\n\n\n
Version 2 is not a single launch. It is a programme of changes across several layers of Paystack’s developer platform, delivered in stages so that existing integrations continue working while the new infrastructure is built alongside them.<\/p>\n\n\n\n
The changes visible so far span four distinct areas.<\/p>\n\n\n\n
New documentation architecture<\/h3>\n\n\n\n
The most immediate signal of the transition is the new documentation site at docs-v2.paystack.com. This is not a visual refresh of the existing docs at paystack.com\/docs. It is a restructured documentation system built on a new architecture, with reorganised navigation, updated guides, and a cleaner separation between conceptual documentation and API reference material.<\/p>\n\n\n\n
Both the old and new documentation sites are currently live and active. This is intentional: developers with existing integrations can continue referencing the familiar documentation while new integrations are built against the v2 docs from the start. The gradual migration of content and developers from one to the other is part of how Paystack is managing the transition without forcing a hard cutover.<\/p>\n\n\n\n
The v2 documentation covers payments, terminal, transfers, identity verification, libraries and plugins, and guides, with the API reference available as a separate section. Over time, as the transition progresses, the old documentation site will be deprecated. No timeline for that deprecation has been publicly announced.<\/p>\n\n\n\n
The JavaScript library: from Popup V1 to Popup V2<\/h3>\n\n\n\n
For developers who integrate Paystack’s checkout experience directly into web applications, the most hands-on change in the v2 transition is the migration from InlineJS Popup V1 to Popup V2. Paystack has published a migration guide for this, and the differences are concrete enough to require deliberate code changes.<\/p>\n\n\n\n
In Popup V1, transactions are initialised with the PaystackPop.setup() method, which is then triggered by calling openIframe(). In Popup V2, this structure is replaced by a cleaner initialisation pattern with updated callback names. The callback() method, which previously indicated a successful transaction, is replaced by onSuccess(). The onClose() method, which fired when a user dismissed the popup, is replaced by onCancel(). Popup V2 also supports modern JavaScript syntax including arrow functions, removing the verbosity that V1 required.<\/p>\n\n\n\n
For any team with an existing web integration, the migration is straightforward but not automatic. Both versions will coexist for a period, but v2 is where new features will be built, and v1 will not receive them. Teams that want access to new checkout capabilities as Paystack adds them will need to migrate.<\/p>\n\n\n\n
Transaction IDs: a breaking change already in effect<\/h3>\n\n\n\n
One of the most significant technical changes in the v2 programme has already been deployed and applies to all integrations regardless of version: transaction IDs are now represented as unsigned 64-bit integers.<\/p>\n\n\n\n
This matters because many common programming environments default to signed 64-bit integers or to 32-bit integers, both of which cannot represent the full range of unsigned 64-bit values. Any application that stores Paystack transaction IDs in a database column typed as a standard integer, or processes them as a default number type in JavaScript (which uses floating-point representation and loses precision beyond 53-bit integers), will encounter errors as transaction volumes grow and IDs exceed the safe representable range.<\/p>\n\n\n\n
The fix is specific to your tech stack. In MySQL, the column should be unsigned bigint. In PostgreSQL, bigint. In Java, long. In C#, unsigned long. In Go, uint64. In Kotlin, ulong. In Swift, uint64. JavaScript applications handling transaction IDs should treat them as strings rather than numbers to avoid precision loss.<\/p>\n\n\n\n
This is a change that does not announce itself loudly until it breaks something in production. If your integration stores or processes transaction IDs and you have not already reviewed the data types involved, this is the change to address first.<\/p>
<\/a><\/div><\/div>\n\n\n\n