This question has been asked so many times, in so many ways, in so many forums; mostly by people that are too lazy to read the manual, or are too inexperienced / incompetent to understand it.
The first paragraph of the Passbook Web Service Reference explains why simply adding a link to an updated pass will not work.
A REST-style web service protocol is used to communicate with your server about changes to passes, and to fetch the latest version of a pass when it has changed. The endpoints always begin with the web service URL, as specified in the pass, followed by the protocol version number. For example, a request for the latest version of the pass of type com.apple.pass.example and serial number ABC123 might look like the following:
The Passbook web service is an integral part of the Passbook eco system. Anyone wishing to issue passes that change their content (either in response to a push message or in response to a user requesting fresh content by pulling down on the back of the pass), needs to implement their own Passbook web service.
This entails building a server capable of responding to the following to authenticated requests from each device that has installed your pass.
There are 5 methods that your web service should respond to:
1. Registering a Device to Receive Push Notifications for a Pass
POST
request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
2. Getting the Serial Numbers for Passes Associated with a Device
GET
request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier?passesUpdatedSince=tag
3. Getting the Latest Version of a Pass
GET
request to https://webServiceURL/v1/passes/passTypeIdentifier/serialNumber
4. Unregistering a Device
DELETE
request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
5. Logging Errors
POST
request to https://webServiceURL/v1/log
In order to have a pass respond to a manual refresh or push request you need to implement at least the first 3 methods. This is because the device will not issue any further requests until it has received a valid response to the registration request.
Furthermore, the web service must be available over https
. An unsecured http
service can be used for development, but production devices will only recognise a webServiceURL key that begins with https
.