The "already verified on a different Apple Account" error when that account cannot be identified is a documented situation. Apple's identity verification links to the government ID itself, and deleting an Apple Account does not automatically release that link. The associated account may have been deleted or terminated without the verification link being cleared. A few things that have helped others in similar cases: Ask Support to escalate, not close. When a case gets closed with "provide the other account's email," that is a dead end if you genuinely do not have that email. Ask to be escalated to the Developer Program Account Resolution team specifically, and ask them to look up the linked account by government ID, not by email address. They have that capability internally. Provide device serial numbers. If you have ever set up a device and gone through Apple verification on it, even just signing in with a different Apple ID, that serial can sometimes be used to cross-reference enrollment history. Share serial numbers of older devices with Support. Reference the closed case explicitly. If case 20000143970410 was closed without a solution, open a new case and cite that number. Ask specifically whether the verification is linked to a terminated or deleted account. If so, there is a separate internal path to release it. The fix has to come from Apple's side. There is no user-side resolution, but the escalation path does exist.

One detail that matters given what you sell, since it is easy to read the condition more strictly than it is written. The waiver condition is about what you distribute on the App Store, not about whether your organization has revenue. It applies as long as you distribute only free apps, with no paid apps and no in-app purchases. Selling physical books and classroom items is not in-app purchase territory to begin with. Apple's guidelines require goods and services that are used outside of the app to be purchased by means other than in-app purchase, so taking payment for physical items through your own payment flow is not offering IAP and does not conflict with the waiver condition. Where it would conflict is digital content consumed inside the app: an e-book readable in your app, a paid course, a subscription. Those are in-app purchase, and that is what removes eligibility. One more thing worth checking before you plan around it. The waiver is available to organizations, not individuals, so the enrollment itself has to be the organization type. That brings the organization requirements with it: a D-U-N-S Number, a publicly available website whose domain is associated with your nonprofit, and a work email address on that same domain. If the 501(c)(3) ends up enrolled as an individual, the waiver is not available at all.

On the cardholder question specifically: Apple's published requirement about using your own card applies to individual enrollment, not to organizations. The wording is "If you're paying by credit card and enrolling as an individual, you must use your own credit card to complete your purchase. If you do not, your enrollment will be delayed and you'll be asked for a copy of your government-issued photo identification." There is no equivalent published rule for organization purchases, so a card in a name other than the Account Holder's is not itself documented as a blocker. One documented cause that is worth ruling out: Apple Account balance is not accepted as payment for memberships, with India as the stated exception. If the purchase ever fell back to a balance rather than the card, that would explain a charge that never appears. On the timing, the only duration Apple publishes at this stage is the confirmation window: "If you haven't received a membership confirmation within 24 hours of your purchase, contact us. Make sure to include your Enrollment ID with your support request." You are far past that, so continuing to press support is the correct path rather than waiting it out. Two practical notes on that. Apple asks for the Enrollment ID specifically, and a Case ID is not the same thing. If your existing case does not have the Enrollment ID in it, adding it is worth doing. And since your organization already shows as approved, the verification stage has passed; what is stuck is the purchase step, which is a different queue from enrollment review. What nobody can tell you honestly is how long the review itself takes, because Apple does not publish a timeframe for it. Any specific number you see quoted is someone's personal experience rather than documentation.

"Mismatch" here almost never means the number is wrong. It means Apple looked up your D-U-N-S record and the details it found do not line up, character for character, with what you typed into the enrollment form. Registering with D&B is only half of it. Apple's check reads three fields off that record - Apple's own wording is that the D-U-N-S Number lets it "verify your organization's identity, legal entity status, and address" - and all three have to agree with the enrollment form. What to check, in this order: Look up the record yourself first. Apple runs a D-U-N-S lookup at developer.apple.com/enroll/duns-lookup/ and it shows you what Apple sees, not what you think D&B stored. Compare it word by word with your enrollment form. Legal name. The usual culprits are the legal form and its position (Ltd, LLC, GmbH, Pvt Ltd, OU), an ampersand versus "and", punctuation, and accented characters. A trading name instead of the registered name will also fail. Address. If you moved and only updated the tax office, D&B still has the old one. Entity status. Apple will not accept a DBA, a fictitious or trade name, or a branch - its wording is that it does "not accept DBAs, fictitious business names, trade names, or branches." If D&B has you filed as something other than the legal entity itself, that reads as a mismatch too. Duplicates. If you applied to D&B more than once you may now have two records, and Apple may be reading the wrong one. That takes longer to untangle than anything else on this list, so avoid creating another one while you wait. When you do find the wrong field, fix it at D&B, not at Apple - Apple only reads what D&B sends. And then wait before retrying: Apple publishes up to 2 business days for updated D&B information to reach it. Resubmitting the same enrollment the same day simply re-reads the old data and fails again.

A few things that may help narrow down where this is actually stuck, since "pending" covers more than one state. The fact that you were able to pay is itself information. For organization enrollments Apple's documented order is verification first, purchase second: "Organizations can review the license agreement and purchase a membership once Apple Developer Support verifies the enrollment information and sends an email with next steps." So if you paid, the entity check most likely already passed, and what is outstanding is something later in the chain rather than your OU documents. Two concrete things to check on your side: The D-U-N-S record. Apple reads it letter by letter and it has to match what you entered. Estonian OU names are a common tripwire here: whether the record says "OU" or the full legal form, where it sits in the name, and whether the registered address is current. If D&B has anything stale, Apple's check keeps failing quietly. Fixing it at D&B takes effect on Apple's side only after propagation - Apple publishes up to 2 business days for that. The Account Holder authority check. Apple requires the person enrolling to be the owner/founder, an executive, a senior project lead, or an employee with legal authority granted by a senior employee - and if you are not the owner/founder, Apple asks for a reference who can confirm that authority. This is the step that most often sits silently after payment, because nobody tells you a reference is being contacted. On the "two business days" you were quoted: the only duration Apple publishes for this is about purchase confirmation - "If you haven't received a membership confirmation within 24 hours of your purchase, contact us. Make sure to include your Enrollment ID with your support request." Apple does not publish a review timeframe for enrollment itself, so a month, while frustrating, is not outside anything documented. Practically: reply on the existing support thread rather than opening new ones (new cases restart the queue), always include the Enrollment ID, and state plainly that payment has cleared and you are asking which specific item is outstanding. Asking "what is missing" gets a more useful answer than "how long will this take".