Problem
Certificates expire on a clock. Merchants find out when checkout fails.
Approach
One tool: what expires, who can fix it, what’s wrong.
Status
Concept, in Apple’s design language.

Context

Three things keep Apple Pay on. All three expire.

Figure 1 Three clocks, one sample merchant
  1. Merchant Identity certificate25 months4 days left
  2. Payment Processing certificate25 months11 days left
  3. Domain verificationUntil the SSL certificate ends6 days left

Time usedApple’s checks: 30, 15, 7 days

The problem

How checkout stops.

Figure 2 From certificate to ticket
  1. 25 months before
    Certificate created, date forgottenProblem 1 · Nobody sees the clock
  2. 30, 15, 7 days before
    Reminders reach one unread inboxProblem 2 · The notice reaches nobody
  3. 2 days before
    Old certificate revoked too earlyProblem 3 · Wrong rotation order
  4. Same week
    Domain check fails, no reason givenProblem 4 · Silent domain checks
  5. Day 0, 08:00
    Apple Pay stops opening
  6. 09:41
    “Apple Pay stopped working”Problem 5 · Tickets without context

The challenge

The challenge

Give every expiry an owner. Make the risky step impossible to do early.

  • See it early
  • Reach a person
  • Safe by default

Five problems, five designs

Problem 01

Nobody sees the clock

TodayExpiries surface one outage at a time.

Figure 3 Expiring list
The design

Everything that expires, in one list.

1

Certificates and domains together.

2

Red under a week, amber under two.

3

Reached a person, or only emailed.

Problem 02

The notice reaches nobody

TodayApple emails one address. Often a stale one.

Figure 4 Owners and escalation
The design

Everyone who can renew, escalating.

1

Why it’s at risk, in one line.

2

Every owner, not just the account email.

3

Each silence widens the circle.

Problem 03

Wrong rotation order

TodayRevoking too early stops checkout at once.

Figure 5 Certificate rotation
The design

Revoke stays locked until it’s safe.

1

Warns before the mistake.

2

Which certificate is serving payments.

3

Unlocks after a real payment.

Key discovery

Only a real payment proves a new certificate works.

Problem 04

Silent domain checks

TodayVerification fails without saying why.

Figure 6 Domain checks
The design

Apple’s checks, with the failing one named.

1

The failing check and its status.

2

When Apple checks again.

3

A fix ready to send.

Problem 05

Tickets without context

Today“Stopped working” could mean anything.

Figure 7 Ticket and timeline
The design

The ticket comes with its timeline.

1

The merchant’s words.

2

What happened, in order.

3

A reply that names the cause.

Trade-offs

Email everyone, or escalate?

Email everyone at 30 days

  • +Nobody is missed
  • −Everyone assumes someone else has it

Escalate only when unansweredChosen

  • +One owner at a time
  • +Ends with a call
  • −Needs current owner data

How I’d measure it

  • Outages avoidedRenewed before the date.
  • Time to first fixTicket to right reply.
  • Notices answeredBy a person, not just delivered.

Looking back

  • 1

    Outages were calendars, not bugs.

  • 2

    Lock the dangerous step.

  • 3

    Design in the platform’s language.

Sources

  1. Apple Developer: Maintaining your environment (Apple Pay on the web)
  2. Apple Developer: Managing payment processing certificates
  3. Apple Developer Forums: Merchant Identity certificate renewal problems
  4. Apple Developer Forums: New certificates not working after update
  5. Apple Developer Forums: Domain renewal fails without errors
  6. Apple Human Interface Guidelines