As Bobson quoted but apparently didn't read, with emphasis added:
The PA-DSS is for software vendors and others who develop payment applications that store, process or transmit cardholder data and/or sensitive authentication data as part of authorization or settlement, when these applications are sold, distributed or licensed to third parties. Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC
PA-DSS is the Payment Application Data Security Standard, an entirely separate document available on the PCISSC website -- click on the Filter box and select PA-DSS. (In the old Web1.0 days I could give a hyperlink but the brave new world requires manual interaction for everything even for the tiny fraction of websites not 'monetizing' their users.)
Nearly all the substantive requirements in PA-DSS are based on requirements in the normal DSS, the one applicable to merchants and service providers (and now issuers) who actually process cardholder data and transactions, but many are adjusted to reflect the software development process. For example, where DSS requires a merchant/etc to configure access privileges for different users based on business need, such as viewing unmasked PAN, PA-DSS requires the application vendor to support such privileges and provide guidance on how the merchant can assign them after installing the software. Where DSS requires the merchant/SP to monitor logs and respond to problems, PA-DSS requires the application provide suitable logs to be monitored. And so on. The requirements about actually operating the network (including quarterly external scans) and physical environment don't apply at all. The only substantive requirement unique to PA-DSS is that you must write and provide an Implementation Guide and some related documentation that the merchant/etc, or a reseller/integrator if applicable (sounds like not in your case), can use in ensuring and documenting their system using your software as a whole satisfies DSS.
The bad news is there is no self-assessment track for PA-DSS application vendors; you must have an audit by a QSA specifically for PA-DSS called a PA-QSA or Payment Application Assessor -- note this is a separate item under the 'Assessors & Solutions' tab which leads to this list.
A possible alternative is that if you are contracted sufficiently under the direction of the merchant(s), they could treat you as effectively in-house, i.e. part of their own development team(s), developing 'solely' for them. But in that case they must be able to produce on demand all your design documents, coding standards, logs showing code changes were reviewed by a second person, training qualifications and possibly background investigations of all staff, etc. This will be very intrusive.
For more on the relationship between DSS and PA-DSS, see page 9 of DSS, particularly the last paragraph, emphasis added:
PCI DSS may apply to payment application vendors if the vendor stores, processes, or transmits cardholder data, or has access to their customers’ cardholder data (for example, in the role of a service provider).