DEV Community: Lian0123 (連永立)

Notes on the Pitfalls of iOS Sandbox Accounts and Apple Pay

Lian0123 (連永立) — Tue, 08 Sep 2026 12:50:39 +0000

Introduction

Why am I writing this article? The reason is simple: a while ago, a new project at my company required us to integrate Google Pay and Apple Pay.

The service had already completed its credit card payment flow. However, management later requested support for Google Pay and Apple Pay as well.

Since none of our previous company projects had integrated Apple Pay, I became the first person in the company to take on this task.

With the help of AI, the payment integration itself was completed in about one day.

However, a new problem came up:

The code was finished, but how were we supposed to test it in the UAT environment?

This is basically a record of my experience and the problems I encountered while testing Apple Pay in the Sandbox environment. I hope it helps other engineers who are stuck in a similar testing environment.

Problem 1: How to Configure the CER and Private Key

At the moment, I only have a .p12 file. The payment integration side has already configured the Apple Pay certificate and generated the corresponding CSR. The only remaining step is to configure the environment variables on the application side.

The contents of a .p12 file are generally as follows:

.p12
├── Certificate
├── Private Key
└── Certificate Chain (may be included)

The overall process is:

.p12
├── Extract the Certificate / PEM
├── Extract the Private Key
└── Verify that the CSR, Certificate, and Private Key belong to the same key pair

The following process uses OpenSSL:

# Inspect the p12 contents without outputting the private key
openssl pkcs12 -info -in apple-pay.p12 -noout

# Extract the certificate
openssl pkcs12 \
  -in apple-pay.p12 \
  -clcerts \
  -nokeys \
  | openssl x509 -out cert.pem

# Extract the private key
openssl pkcs12 \
  -in apple-pay.p12 \
  -nocerts \
  -nodes \
  | openssl pkey -out private-key.pem

-nodes means that the exported private key will not be encrypted again. Therefore, the generated private-key.pem must be stored securely. It should never be committed to Git or printed in logs.

Verifying That the Certificate and Private Key Match

The simplest way is to extract the public key from the certificate and the private key, then compare their hash values.

# Public key from the certificate
openssl x509 -in cert.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | shasum -a 256

# Public key corresponding to the private key
openssl pkey -in private-key.pem -pubout \
  | openssl pkey -pubin -outform DER \
  | shasum -a 256

If the hash values produced by the two commands are identical, the certificate and private key belong to the same key pair.

If you also need to verify the CSR, run the following command:

# Public key corresponding to the CSR
openssl req -in request.csr -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | shasum -a 256

If the hash values of the CSR, certificate, and Private Key are all identical, it means that all three use the same key pair.

Architecture

Terminology

p12

.p12 is a PKCS#12 container file. It can usually contain:

Certificate
Private Key
Certificate Chain
Password protecting the private key

Therefore, under normal circumstances, the .p12 file already contains the certificate and private key required by the payment service.

However, you still need to confirm the purpose of the .p12 file. Common Apple Pay certificates include:

Merchant Identity Certificate: Used to authenticate Merchant Sessions for Apple Pay on the Web.
Payment Processing Certificate: Used to encrypt payment data. Decryption is usually handled by the merchant or the PSP (Payment Service Provider).

These two certificates have different purposes. You cannot assume that every .p12 file can be used as every type of Apple Pay certificate.

PEM

PEM stands for Privacy-Enhanced Mail. It is a text-based encoding format. Certificates, private keys, and CSRs may all be stored in PEM format.

Example of a certificate PEM:

-----BEGIN CERTIFICATE-----
...
...
...
-----END CERTIFICATE-----

Private Key

A private key is also usually stored in PEM format.

-----BEGIN PRIVATE KEY-----
...
...
...
-----END PRIVATE KEY-----

CSR

CSR stands for Certificate Signing Request.

The usual process is to generate a CSR first, then upload it to Apple Developer to obtain a CER.

A CSR contains the public key, application information, and a signature generated using the corresponding Private Key. However, it does not contain the Private Key itself.

-----BEGIN CERTIFICATE REQUEST-----
...
...
...
-----END CERTIFICATE REQUEST-----

CER

A CER is a certificate file issued by Apple. Its file extension is usually .cer.

Problem 2: The Apple Pay Screen Works, but the Card Cannot Be Added

Situation

The Apple Pay configuration for the website was complete, and the Apple Pay button was displayed correctly. Clicking the button also opened the Apple Pay payment screen.

I then opened the Apple Pay Sandbox Testing page and tried to add Visa, Mastercard, and JCB test cards to Wallet.

Many iOS testing guides mention enabling Developer Mode and adding the newly created Sandbox Account to the Sandbox settings. However, none of the cards could be added.

Many guides introduce the following steps:

Enable Developer Mode.
Create a Sandbox Account.
Add the Sandbox Account to the test settings.

In reality, these steps are not enough.

What Is Developer Mode?

Developer Mode allows the device to run apps that are still under development.

Enabling Developer Mode does not automatically switch the device to Apple Pay Sandbox mode, nor does it mean that test cards can be added directly to Wallet.

What Is a Sandbox Account?

A Sandbox Account is a test account created in App Store Connect. It is used to test Apple Pay, In-App Purchases, and other sandbox features.

It can usually be created here:

App Store Connect
→ Users and Access
→ Sandbox
→ Testers

When creating the account, make sure that the Email address has not already been registered as a regular Apple Account. Using an existing Email address may cause login or verification problems.Official Apple Sandbox Account documentation

The Correct Apple Pay Testing Process

The general Apple Pay Sandbox testing process is as follows:

Create a Sandbox Tester Account in App Store Connect.
Confirm that the test device supports Apple Pay.
Set the device region to an Apple Pay-supported region, such as Taiwan.
Sign out of the Apple Account or iCloud account previously used on the test device.
Sign in to the test device using the Sandbox Account.
Open Wallet.
Select the option to add a credit or debit card.
Manually enter the test card information provided on Apple’s official page.

Apple’s test card page mainly provides test FPANs, CVVs, CVCs, and expiration dates. It is not a page that directly adds cards to Wallet.

It is also recommended to use a physical device for Apple Pay testing. Make sure the device has a passcode, Face ID, or Touch ID configured.

Apple’s official process is to sign out of the existing iCloud account, sign in to the device using the Sandbox Tester Account, and then manually add the test card from Wallet.Apple Pay Sandbox Testing

Problem 3: iCloud 34608 Appears After Signing In to the Sandbox Account

Situation

Some people may have already signed out of their original Apple Account and attempted to sign in with a Sandbox Account.

However, after entering the account and password, the iPhone may remain stuck on the account setup animation and eventually display the iCloud 34608 error.

This error message is not very informative. Apple has not published a complete official explanation for error 34608, and the information available online is scattered. Therefore, the following is the approach I used to troubleshoot the problem.

First, make sure that the registered Email address is new and has never been registered as a regular Apple Account. If you have made it this far, I believe most readers are probably not stuck at this step.

After confirming that the Email address is new, log in to the Apple Account management page using a browser.

If the system asks you to complete any of the following verification steps, make sure to complete them:

Phone number verification
Two-factor authentication
Account security settings
Acceptance of the terms and conditions

This is a common problem in corporate testing environments. A company may use a test device that has not completed phone verification or multi-factor authentication. This can cause an iCloud error during account login and prevent the Apple Account from being added to the iPhone.

After completing the verification steps above, return to the test device and sign in to the Sandbox Account again. If it still fails, restart the device, confirm that the original Apple Account has been signed out, and try again.

Final Testing Checklist

If you are testing Apple Pay Sandbox from scratch, I recommend checking the following items in order:

The Merchant ID has been created.
The purpose of the Apple Pay certificate has been confirmed.
The CSR, certificate, and Private Key have been verified to belong to the same key pair.
A Sandbox Tester Account has been created in App Store Connect.
The Email address used by the Sandbox Account has never been registered as a regular Apple Account.
The test device supports Apple Pay.
Developer Mode is enabled on the test device.
The test device region is set to an Apple Pay-supported region.
The original Apple Account or iCloud account has been signed out.
The test device is signed in with the Sandbox Account.
The official Apple test card has been manually added to Wallet.
The Apple Pay Web Merchant Domain has been verified.
The website uses HTTPS and the server’s TLS configuration has been checked.
Sandbox and Production payment environments are not mixed.
Payment tokens and Private Keys are not printed in logs.

Conclusion

This article mainly covered the following three points:

A .p12 file is a container, not simply a certificate. You need to extract the certificate and Private Key from it and verify that they belong to the same key pair.
Apple Pay Sandbox is not just about enabling Developer Mode. You also need to create a Sandbox Account correctly, sign in to the test device, and manually add a test card through Wallet.
If iCloud 34608 appears, the problem may not be in the Apple Pay code. It may be caused by incomplete Sandbox Account verification or an incomplete device login process.

The most misleading part of Apple Pay testing is assuming that “the payment screen appears” means the entire payment flow is working correctly.

Certificates, accounts, Wallet, Apple Pay Sessions, and the final decryption of payment data all have their own testing requirements.

By checking each stage separately, you can usually identify the actual source of the problem much faster.

The original article was written in Traditional Chinese, and the Japanese and English versions were translated using ChatGPT.

Notes on Introducing AI into Vibe Coding Development (Part 1): Why Does AI “Cut Corners”?

Lian0123 (連永立) — Sun, 19 Jul 2026 04:03:02 +0000

Introduction

From Vibe Coding to Harness Engineering, integrating AI into software development has become one of the industry’s most discussed topics. Many companies are adopting AI to improve productivity, while new models and tools optimized for programming continue to emerge.

Choosing the right model can save you from many unnecessary detours. But if your prompt is poorly designed, AI may lead you even further away from your actual goal.

This article summarizes several common mistakes I have observed while introducing AI into development workflows. These principles apply not only to everyday prompting, but also to the design of reusable skills, project rules, and engineering workflows.

Keep one thing in mind: when AI starts to “cut corners,” humans usually pay for it with more tokens and more time spent fixing the result.

Why Does AI “Cut Corners”?

Anyone familiar with deep learning may have heard of specification gaming or reward hacking.

In simple terms, an AI system may exploit gaps in an instruction or evaluation rule to satisfy the visible objective at the lowest possible cost. The task may appear complete, while the output is useless—or even contradicts the real intention behind the request.

A Simple Example

Imagine a student named Xiaoming who receives 100 units of allowance every day. To encourage him to study, his parents require him to take a practice exam each day:

If his score drops by 10 points, his allowance is reduced by 10 units.
If his score rises by 10 points, his allowance increases by 10 units.

Xiaoming scores zero on the first day, so his allowance drops to 90 units. He soon realizes, however, that if he continues scoring zero every day, his score will never fall below the previous day’s result. He can keep receiving the full 100 units without studying.

Xiaoming has not violated the rules, but the system has completely failed to achieve its purpose. His parents wanted him to study, yet they accidentally created an optimal strategy in which he can avoid studying and still receive a stable allowance.

A Software Engineering Example

Suppose an engineer asks an AI agent to “fix the bug in this program.”

Without additional constraints, the AI could theoretically delete the faulty code—or remove the entire feature. If the program no longer exists, the error can no longer occur. That technically eliminates the bug, but it clearly does not satisfy the user’s real need.

In Vibe Coding, AI often gravitates toward the fastest, cheapest, and easiest-to-mark-as-complete solution. If a prompt describes only the surface-level objective without defining the intent, constraints, and acceptance criteria, the result can easily diverge from expectations.

Improving AI Behavior Through Better Instructions

Method 1: Provide a Reference Example

One of the most effective approaches is to provide a correct example and ask the AI to follow an established pattern.

The goal is not to prevent the AI from reasoning. It is to reduce unnecessary guesswork. When naming conventions, file structure, interface style, and implementation patterns are demonstrated clearly, the AI is less likely to misunderstand the task, make implementation mistakes, or hallucinate nonexistent behavior.

This approach is especially useful for:

interface development in large projects;
building a new page based on an existing one;
integrating third-party APIs;
reusing established components, tests, or data formats;
implementing features with complete official documentation.

Instead of saying, “Build me a new page,” say, “Implement page B by following page A’s directory structure, component boundaries, and error-handling pattern.”

Method 2: State Explicit Prohibitions

Another common technique is to turn known risks and failure modes into explicit prohibitions.

For example:

Do not remove existing functionality.
Do not disable tests to make the test suite pass.
Do not replace a production API with mock data unless clearly instructed.
Do not change the public interface.
Do not place keys, tokens, or personal data in source code.
Do not perform a large refactor before confirming the impact.

This reflects a useful practice in AI-assisted development: turn previous mistakes into reusable rules. Whether those rules live in AGENTS.md, CLAUDE.md, a skill, or a team knowledge base, the purpose is the same—to prevent known failures from happening again.

This method works well when the risks and operational boundaries are already understood. However, more prohibitions do not automatically produce better results. Too many rules, conflicting rules, or rules without priorities can overload the context and bury the constraints that matter most.

Method 3: Require a Detailed Plan First

One of the central benefits of plan modes and skills is that they break work into reviewable steps.

A useful implementation plan should include at least:

goals and non-goals;
the expected scope of changes;
implementation order;
potential risks;
testing and verification methods;
completion criteria.

When the workflow is written down, humans can identify misunderstandings before the AI begins making changes. This also reduces the chance of unexpected actions during execution.

This approach is particularly suitable for new projects, large refactors, and feature development in projects with an established knowledge base.

Its limitation is equally clear: the quality of the plan depends on the completeness of the available information. If an important condition is missing during planning, the AI may faithfully execute a plan that looks complete but is fundamentally wrong.

A more mature approach is to maintain the following information at the documentation level:

development rules;
architecture and feature responsibilities;
change history;
risk assessments;
acceptance criteria;
known issues and the reasoning behind past decisions.

Together, these materials form a living project knowledge base. I will explore this topic in a future article on AI Living Documentation.

Method 4: Define the Expected Outcome Clearly

If you can describe exactly what “done” should look like, the AI’s output is more likely to converge on the intended result.

For front-end work, this may include a wireframe, design mockup, interaction flow, target screenshot, or existing page. For back-end work, it may include an API specification, input and output examples, error codes, and performance requirements.

In addition to explaining what must be built, define:

which existing behaviors must remain unchanged;
which scenarios must succeed;
which errors must be handled correctly;
how completion will be demonstrated.

Clear acceptance criteria prevent the AI from treating “the code has been written” as equivalent to “the feature is complete.”

Common Problems in Practice

Problem 1: Claiming Completion Without Verification

Suppose a user asks an AI agent to integrate a particular library. If the model misunderstands the library’s version, API, or documentation, the generated code may look plausible while failing at runtime.

The original instruction might be:

Add Live2D to this web page so that the character on the page can be animated.

This describes the feature but does not require the AI to verify the result. A stronger instruction would be:

Add Live2D to this web page so that the character on the page can be animated.

Confirm that the Live2D assets load correctly, the model is visible, and its animation plays.

Run the project and verify that no related errors appear in the browser console.

Do not break existing page functionality. If any item cannot be verified, clearly identify it and explain why.

When finished, list the changed files, verification method, and test results.

“Please ensure code quality” is still too abstract. A better approach is to translate quality into executable and observable conditions:

the project builds successfully;
automated tests pass;
the feature works in the specified environment;
no new errors appear in the browser console;
existing functionality remains intact;
any unperformed verification is clearly disclosed.

The key principle is that development, testing, and verification are separate steps performed in sequence. Writing the code does not mean the tests have passed, and passing tests does not necessarily mean the user’s need has been satisfied.

If this workflow is used repeatedly, encode it in a skill, project rule, or standard checklist instead of relying on an ad hoc reminder every time.

Problem 2: Ambiguous Terms Create Divergent Interpretations

Humans cannot read minds, and neither can AI.

When a requirement is unclear, the AI can only fill in the missing information using its prior knowledge, the current context, and common conventions. Its answer may be reasonable without being what the user actually wanted.

For example, “menu” in an application could refer to:

the main menu;
the settings menu;
a context menu;
the top navigation bar;
a mobile side menu.

Consider this instruction:

Add an “Open File” option to the menu.

The AI has to infer which menu should be changed. Even if it chooses the wrong location, it may still conclude that the task is complete.

A clearer version would be:

In the desktop application’s top-level File menu, add an “Open File” option directly below “New File.” When clicked, it should open the system file picker and allow the user to select a .json file. Cancelling the picker must not display an error. Do not modify the context menu or the settings page.

The more concrete the description, the fewer semantic branches remain—and the less likely the AI is to make the wrong assumption.

Conclusion

When AI “cuts corners,” the cause is often not attitude but incomplete definitions of the goal, constraints, and acceptance criteria.

If you tell an AI only what to finish, it may choose the shortest path. If you also explain why the task matters, what must not be broken, how the result should be verified, and what counts as complete, the quality of its output becomes far more consistent.

An effective AI development workflow is not simply a longer prompt. It is a system that continuously accumulates reference examples, prohibitions, implementation plans, acceptance criteria, testing procedures, and project knowledge.

Next: Why Am I Burning Through Tokens So Quickly?

Have you ever asked AI to solve one simple problem, only to watch the token usage grow until your wallet starts to worry? The reason may not be that the model talks too much. Your development process may be repeatedly paying the cost of misunderstandings.

Stay tuned for the next article.

The original article was written in Traditional Chinese, and the Japanese and English versions were translated using ChatGPT.

Notes on Introducing AI into Vibe Coding Development (Part 0) - Why I Am Writing This Article

Lian0123 (連永立) — Thu, 02 Jul 2026 16:57:35 +0000

What Is Happening in the Software Industry Now?

In recent years, with the emergence of general-purpose artificial intelligence such as ChatGPT and Claude Code, often referred to as AGI, companies have increasingly begun introducing AI into their workflows.

Starting in June 2026, GitHub Copilot AI made a major change. It moved away from the PRU model, or premium request units, which was based on request counts, and shifted toward a model calculated using AI Credits. As a result, the execution cost for an engineer developing a feature, reviewing PRs, organizing documentation, and performing other tasks has gradually increased.

Some developers even used up an entire month’s allowance on the very first day GitHub Copilot AI adopted the AI Credit model. This shift toward token-based pricing is becoming increasingly mainstream. It also places more restrictions on using AI within workflows. If you are not careful, your usage can run out quickly, and costs can continue to rise. Worse still, this type of pricing model is likely to become a broader trend among AI service providers.

Jensen Huang once said:

If that $500,000 engineer did not consume at least $250,000 worth of tokens, I am going to be deeply alarmed.

The question today is no longer whether we should use AI. After all, not every company is like NVIDIA, with the freedom to consume tokens at scale. The real issue is the conflict between problem-solving, money, and time.

Solving problems and controlling costs have already become conflicting forces. The future direction of the software market will be about solving problems effectively while keeping costs under control. It will not be about how many tokens you used to solve something, but about achieving the greatest benefit with the lowest possible cost.

What Should Business Managers and Development Leads Do Next?

Clearly, the first step is to identify what qualities and capabilities future technical talent should have:

The ability to break down large problems and requirements, extract the key points, group them properly, and find the best solution
The ability to simplify AI behavior so it can be executed at the lowest possible cost
The ability to achieve maximum benefit with the fewest tokens

Here is an evaluation framework for companies, including both positive and negative evaluation points.

Positive Evaluation Points

If the company is willing to spend money to solve problems:

Has this problem been troubling the company for a long time? Was it difficult to execute through conventional methods because of staffing, scheduling, or other reasons?
Has AI effectively replaced existing talent resources in the way an expert system might? While ensuring correctness, has it saved human effort?
Was the problem solved quickly? Did it create additional time costs?

Negative Evaluation Points

If the company is relatively conservative:

Will this adjustment reduce future changes, or will it increase them? How should we limit the damage?
If problems occur, are the losses acceptable? For example: time, reputation, and financial cost.
How much benefit can this adjustment bring? Compared with problem-solving costs and personnel costs, how much money does it actually save?
Will future maintenance costs decrease? Or will AI make them higher and unnecessarily so?

In practice, what business managers need even more is a cost plan:

How much cost are we willing to invest in solving the problem?
Is the risk of cost increase controllable?
Are there audit points in place to control costs?

Regarding the common online discussion that AI will replace software engineers, my view is relatively optimistic. There are many detailed technical issues that bosses or non-engineering project managers simply cannot fully grasp. When a company truly lays off all of its software talent, that is when the real disaster begins.

That said, it is undeniable that Junior Engineers will become increasingly rare in the future. The technical threshold will become higher, because using AI well requires the corresponding knowledge. In contrast, Senior Engineers who can combine experience and expertise will become one of the strongest resources in the market.

The knowledge and experience of software professionals will become an important dividing line.

Here is a simple example. Suppose a project developed through Vibe Coding suddenly encounters a serious bug in production. Every minute the problem exists causes the company to lose money.

If you were the manager, would you want the developer to search for the answer as if rolling dice? Or would you want the developer to quickly identify the root cause?

I also like this saying:

People can never imagine what lies outside their own understanding.

The knowledge of a project member is the key to future product maintenance.

Felix Rieseberg, Engineering Lead at Claude Cowork, also said:

The biggest barrier to AI adoption is people not realizing they can ask AI to solve almost any problem… The gap isn't technical; it's psychological.

Felix Rieseberg points out that the reason people fail to use AI well lies in imagination. What you can think of determines what you can ask. When using today’s top-tier models, the core problem is not always that the result falls short of expectations. More often, it is that the user has not described the requirements clearly enough, causing the AI to produce results that do not match what was expected.

Of course, the input and output limitations of model context, as well as the model’s byte-processing issues, must first be addressed.

Next Article: Why Does AI Get Lazy?

The next article will discuss a common phenomenon:

Why is it that when two teams use the same AI, one team significantly improves its efficiency, while the other sees almost no improvement in productivity?

Many times, it is not that AI does not understand. Rather, it is...

Stay tuned.

The original article was written in Traditional Chinese, and the Japanese and English versions were translated using ChatGPT.