Filter
-
Content Type
-
Category
Mobile/Wearable
Visual Display
Digital Appliance
Platform
Mobile/Wearable
Visual Display
Digital Appliance
Platform
Filter
tutorials
blogsamsung wallet provides powerful tools for partners to engage with their users and improve the user experience. push notification is one of these features, allowing partners to send customized notifications to their users. but before they can do that, partners need to create a notification template and receive approval for it from samsung. partners can create individual notification templates from the wallet partners portal. as a partner, if you need to create a large number of card notifications, the adding notification templates server api comes in handy. in the example scenario in this blog, we create a notification template from a partner's server using the adding notification template api. system requirements the adding notification template api has the following prerequisites: complete the onboarding procedure to obtain the required security certificates if you are new to samsung wallet, and create your wallet card. get permission from samsung to use the adding notification template api as explicit permission is needed. reach out to samsung developer support for further assistance. api fundamentals to create a notification template, you need to handle an http post request which contains the endpoint, headers, and a body. for a successful execution of the api, you need to follow the following specification. endpoint: use the following url as endpoint. url https://tsapi-card.walletsvc.samsung.com/partner/v1/card/template/{card id}/notification headers: to ensure secure communication between the samsung server and the partner server, implement the following headers. authorization: bearer token for authentication. for details, follow rest api authorization token. x-smcs-partner-id: use the samsung wallet partner id. x-request-id: a unique uuid string that identifies each request. body: contains detailed template data in the jwt token format. see the adding notification templates for a detailed api specification. api implementation the steps below show how to implement the adding notification template api. for a better understanding of the implementation process, download the sample source code. certificate management the keymanager class is a static utility class that provides methods for loading cryptographic keys from files. this separation of concerns ensures that certificate handling logic is isolated and reusable. loading public keys from certificate files first, you need to load rsa public certificates from x.509 certificate files. the getpublickeyrsa() method loads rsa public keys from the partner.crt and samsung.crt files you received during the onboarding process. if the certificate doesn't contain an rsa key, this method raises an exception. public static rsa getpublickeyrsa(string certpath) { try { var cert = new x509certificate2(certpath); return cert.getrsapublickey() ?? throw new invalidoperationexception("certificate does not contain rsa public key"); } catch (exception ex) { throw new invalidoperationexception($"failed to load certificate: {ex.message}", ex); } } loading private keys from a pem file the getprivatekeyrsa() method loads an rsa private key from a pem file. this is used to generate jwt tokens. public static rsa getprivatekeyrsa(string pempath) { try { string keydata = file.readalltext(pempath); // remove pem headers and whitespace keydata = keydata.replace("-----begin private key-----", "") .replace("-----end private key-----", "") .replace("-----begin rsa private key-----", "") .replace("-----end rsa private key-----", "") .replace("\n", "") .replace("\r", "") .trim(); byte[] keybytes = convert.frombase64string(keydata); var rsa = rsa.create(); rsa.importpkcs8privatekey(keybytes, out _); return rsa; } catch (exception ex) { console.writeline($"failed to load private key from {pempath}: {ex.message}"); return null; } } token generation the tokengenerator class is the heart of the implementation, responsible for creating secure tokens using cryptographic techniques. constructor and properties the class stores all necessary cryptographic keys and identifiers. private string _partnerid = ""; private string _certificateid = ""; private readonly rsa _samsungpublickey; private readonly rsa _partnerpublickey; private readonly rsa _partnerprivatekey; public tokengenerator(string partnerid, string certificateid, rsa samsungpublickey, rsa partnerpublickey, rsa partnerprivatekey) { _partnerid = partnerid; _certificateid = certificateid; _samsungpublickey = samsungpublickey; _partnerpublickey = partnerpublickey; _partnerprivatekey = partnerprivatekey; } generating an authentication token an authentication token proves that your request to samsung's server is legitimate. it contains the following: the api method and path being accessed. var authpayload = new dictionary<string, object> { ["api"] = new dictionary<string, string> { ["method"] = "post", ["path"] = $"/partner/v1/card/template/{cardid}/notification" } }; timestamp and other metadata like certificate id. retrieve this metadata from my account > encryption management in the wallet partners portal. a digital signature that verifies the sender's identity. the token is used in the authorization header of the http request. public string generateauthtoken(dictionary<string, object> authpayload, string contenttype_auth) { string datastr = jsonserializer.serialize(authpayload); string authtoken = signjws(datastr, contenttype_auth); return authtoken; } generating a notification template token next, generate the jwt token for notification template data (ntemplate). it is recommended to generate this token after a user action. for details about the jwt format, follow card data token (cdata). preparing a notification template define the notification template according to the following code snippet. define your message details and message type here. get details about the template fields from the “[request]” section of the adding notification templates documentation. var notificationtemplate = new { type = "m", messagetype = "m", messagedetails = new[] { new { languagecode = "en", message = "sample merchant push notification message." } }, forcesaveyn = "n" }; noteuse forcesaveyn = “y”, if you want to save the template even if the message is detected as harmful. if your message is detected as harmful, your template can be rejected by samsung. the default value of the forcesaveyn property is “n”. implementing encryption (jwe) the notification template data or payload is encrypted using the samsung public key and this encrypted payload is used for signing. public string generatecdata(string payloaddata, string notification) { string jwetokenstring = jwt.encode(payloaddata, _samsungpublickey, jwealgorithm.rsa1_5, jweencryption.a128gcm); string jwttokenstring = signjws(jwetokenstring, notification); return jwttokenstring; } implementing jws signing the encrypted jwe token is then signed with the partner's private key. this signature proves the token originated from a legitimate partner. samsung can verify this signature using the partner's public key. noteuse auth as the content type when signing an auth token and use notification as the content type when signing the notification template data. private string signjws(string payload, string contenttype) { try { // create header var header = new dictionary<string, object> { ["alg"] = "rs256", ["cty"] = contenttype, ["partnerid"] = _partnerid, ["ver"] = 3, ["certificateid"] = _certificateid, ["utc"] = datetimeoffset.utcnow.tounixtimemilliseconds() }; return jwt.encode(payload, _partnerprivatekey, jwsalgorithm.rs256, header); } catch (exception ex) { throw new invalidoperationexception($"jws signing failed: {ex.message}", ex); } } building and executing the post request the next stage of the process is to construct the http post request to generate a new notification. client.defaultrequestheaders.clear(); client.defaultrequestheaders.add("authorization", $"bearer {authtoken}"); client.defaultrequestheaders.add("x-smcs-partner-id", partnerid); client.defaultrequestheaders.add("x-request-id", requestid); try { httpresponsemessage response = await client.postasync(endpoint, content); response.ensuresuccessstatuscode(); string responsecontent = await response.content.readasstringasync(); console.writeline("successfully generated notification template: " + responsecontent); } catch (httprequestexception e) { console.writeline("failed to generate notification template: " + e.message); } catch (exception e) { console.writeline("unexpected error during http request: " + e.message); } running the sample application once you are done with the above steps, open the sample project and do the following: update the partnerid, cardid, and certificateid values in the src/program.cs file with your actual values. place your partner.crt, samsung.crt and private_key.pem files in the /cert directory. navigate to the src directory, then build and run the project. find the details for responses and errors from the [response] section of the documentation. # build the project dotnet build # run the application dotnet run conclusion now that you know how to create a new notification template using the adding notification template api, you can implement it with your server if you need to generate a larger number of notification templates at once. additional resources for more information on this topic, consult the following resources: download the complete source code official samsung wallet api documentation send push notifications to samsung wallet users using the send notification api blog
M. A. Hasan Molla
tutorials
blogsamsung wallet provides an e-wallet service to its customers through wallet cards. adding a card to the user device is normally triggered by user interaction, cards are added to their device when the add to wallet button or link is pressed. the adding wallet cards api provides the functionality to add cards to user devices directly without user interaction. a partner can provide wallet cards to the user’s wallet directly using the user’s email or mobile number. this article demonstrates a complete implementation of the adding wallet cards api. in the example scenario, we add a coupon type card to a user device from a partner’s server using this api without any user interaction. system requirements the adding wallet cards api has the following prerequisites: new samsung wallet users must first complete the onboarding procedure and obtain the required security certificates. create a new coupon card template through the wallet partners portal and launch the card. as a partner you can also create a card template through the partner server. for more details, refer to the create samsung wallet card templates using the server api. using the adding wallet cards api requires explicit permission from samsung. contact samsung developer support for authorization. api fundamentals this restful interface enables partners to deliver wallet cards directly to user accounts from their servers. endpoint: the service url where card addition requests are processed. https://tsapi-card.walletsvc.samsung.com/atw/v1/cards/{cardid} headers: only verified partners can utilize this api. header information establishes secure communication between the partner and samsung servers. authorization: bearer token authentication. refer to json web token documentation for specifications. x-smcs-partner-id: your unique partner identifier required for api access. x-request-id: a unique uuid string that identifies each request. body: must include a cdata parameter containing a jwt token with card details and user account information. detailed api specifications are available in the official documentation. api implementation process the adding wallet cards api enables partners to deliver cards directly to the user's account or wallet. follow this step-by-step approach to implement the api. for a better understanding of the overall process, download the sample source code. step 1: cryptographic key management extract necessary keys from security certificates for jwt token generation in subsequent steps. public key retrieval the following function extracts public keys from partner.crt and samsung.crt certificate files received during the onboarding process. def getpublickey(crt_path): """ extract public key from a .crt file. """ try: with open(crt_path, "rb") as f: crt_data = f.read() certificate = x509.load_pem_x509_certificate(crt_data, default_backend()) public_key = certificate.public_key() public_key_pem = public_key.public_bytes( encoding=serialization.encoding.pem, format=serialization.publicformat.subjectpublickeyinfo ) return public_key_pem except exception as error: print(f"error reading public key from {crt_path}: {error}") return none private key retrieval this function retrieves the private key from the .pem file generated during the onboarding process. def getprivatekey(pem_path): ''' extract private key from a .pem file. ''' try: with open(pem_path, "rb") as data: private_key = serialization.load_pem_private_key( data.read(), password=none, backend=default_backend() ) return private_key except exception as error: print(f"error reading private key from {pem_path}: {error}") return none step 2: authentication token creation samsung validates each api request through an authorization token in jwt format. to generate a valid authentication token: construct an authheader with auth as the payload content type. include the certificate id from my account > encryption management in the wallet partners portal. build the payload using the authheader structure. generate the final authorization token. the following code snippet implements the steps above. def generateauthtoken(partnerid, certificateid, utctimestamp, privatekey, cardid): auth_header = { "cty": "auth", "ver": 3, "certificateid": certificateid, "partnerid": partnerid, "utc": utctimestamp, "alg": "rs256" } auth_payload = { "api": { "method": "post", "path": f"/atw/v1/cards/{cardid}" }, } auth_token = jwt.encode( payload=auth_payload, key=privatekey, algorithm='rs256', headers=auth_header ) return auth_token step 3: card data token generation (cdata) the request payload requires a cdata parameter containing a jwt token with card information and user details. follow these steps to construct the cdata token. card information structure build a card data object containing all necessary information about the card to be delivered and the target user account. cdatapayload = { "card": { "type": "coupon", "subtype": "others", "data": [{ "refid": "e389dc8a-4616-494c-a8b3-80380f449fc2", "createdat": 1727913600000, "updatedat": 1727913600000, "language": "ko", "attributes": { "title": "strawberry icecream-1", "orderid": "order-001", "groupingid": "grouping-001", "mainimg": "https://djcpagh05u38x.cloudfront.net/wlt/kr/stg/ihghulmhriqfhi73ydqzca/ldzf4fwlq9i5iqoym1r2yw.png", "brandname": "cioud icecream", "expiry": 1762225720029, "issuedate": 1727913600000, "redeemdate": 1727913600489, "noticedesc": "<div>▶precautions<br>-this product is an example image and may be different from the actual product. <br>-only available within the expiration date.<br><br>", "editableyn": "n", "deletableyn": "y", "displayredeembuttonyn": "n", "addtowalletcouponyn": "y", "notificationyn": "y", "applinklogo": "https://play-lh.googleusercontent.com/o5iwmhhbrmiga_4xdsxmizthld-wwu2ln6fbz6znpdlmkif0i98sfhtwzkyzjan-tw=w240-h480-rw", "applinkname": "cioud icecream", "applinkdata": "https://www.samsung.com/us", "barcode.value": "1111222233334444", "barcode.serialtype": "barcode", "barcode.ptformat": "barcodeserial", "barcode.ptsubformat": "code128" }, }] }, "account": { "type": "email", "value": "example@samsung.com" } } cdata jwt token construction generate the jwt token using the following implementation. additional information about the jwt format is available in the card data token section of the security documentation. def generatecdatatoken(partnerid, samsungpublickey, partnerprivatekey, certificateid, utctimestamp, data): jwe_header = { "alg": "rsa1_5", "enc": "a128gcm" } jwe_token = jwe.encrypt( data, samsungpublickey, encryption=jwe_header["enc"], algorithm=jwe_header["alg"] ) print(f"jwe_token: \n{jwe_token}\n") jws_header = { "alg": "rs256", "cty": "card", "ver": 3, "certificateid": certificateid, "partnerid": partnerid, "utc": utctimestamp, } jws_token = jws.sign( jwe_token, key=partnerprivatekey, algorithm='rs256', headers=jws_header ) print(f"jws_token: \n{jws_token}\n") return jws_token step 4: build http request and execute with all required components prepared, construct the card addition http request using the following code structure: # --- prepare json body (python dictionary) --- c_data_json_body = { "cdata": cdatatoken } # --- build http request --- headers = { "authorization": "bearer " + authtoken, "x-smcs-partner-id": partnerid, "x-request-id": requestid, "x-request-cc2": "kr", "content-type": "application/json" } # --- execute http request --- try: response = requests.post(endpoint, json=c_data_json_body, headers=headers) response.raise_for_status() print("wallet card added successfully: " + json.dumps(response.json())) except requests.exceptions.requestexception as e: print("failed to add wallet card:") print(f"error: {e}") if response: print("response body:", response.text) running the application once the four steps described above are implemented, open the sample project and do the following: update the partner id, certificate id, and card id values in src/main.py with your actual credentials. replace the partner.crt, samsung.crt and private_key.pem files with your credential files in the /cert directory. install all dependencies listed in the requirements.txt file using command pip install -r requirements.txt. run the main script using the command python src/main.py in the terminal. after successful execution of the requests, you will get a success message. get the full response code in the response section of the documentation. a push notification is sent to the user’s device to confirm the successful card registration. once this is done, open your samsung wallet and navigate to the coupon card list and you will find the card there. conclusion now that you have familiarized yourself with the process of adding cards to the user device using the adding wallet cards api, you can implement this logic to your server and use it to improve your card management. additional resources for more information on this topic, consult the following resources. complete source code create samsung wallet card templates using the server api official samsung wallet api documentation
M. A. Hasan Molla
Develop Samsung Wallet
docnotification for partners deliver personalized push messages to samsung wallet users, linked to their wallet cards samsung wallet enables authorized partners to send targeted push notifications using pre-approved message templates this feature supports marketing, transactional, and engagement-driven use cases only partners with administrative approval can access and use the notifications feature the notifications tab is hidden for unauthorized accounts notification workflow overview step 1 create notification template partners can create push message templates through the partner portal or notification api templates define the structure and content of the notification type only merchant push is supported message category choose from marketing or other variables use dynamic placeholders with {{ }} syntax e g , hello {{name}}, your pass for {{event}} is ready if your wallet card supports multiple languages, a message template must be provided for each language variant after drafting the message run harmfulness check to detect prohibited content results pass or fail even if failed, templates can still be submitted but may be rejected in the next step step 2 request template approval once the template is complete click the request approval button in the portal an administrator will review the content if rejected the reason is provided via system email partners can revise and resubmit the template for approval if approved the approved date will appear in the portal the template becomes eligible for use in the notification api step 3 push notification with template once a template is approved, partners can push notifications to users linked to their wallet cards using a secure post api request required parameters template id – issued after template approval reference id – a unique identifier tied to the user’s wallet card created during the add to wallet process only pre-approved templates can be used in push requests step 4 monitor impressions and clicks after the push is delivered, partners can track impressions – number of users who viewed the notification clicks – number of interactions with the push these metrics can be accessed through the partner portal dashboard, enabling performance evaluation of each campaign send notification this api sends notifications to end users who have added the wallet card [request] type value description method post url /{cc2}/wltex/cards/{card id}/notifications/{template id}/send header authorizationstring 1024 required credential token the token can have prefix "bearer" as an authorization type e g , bearer <credentials> * refer to authorization token for more details x-smcs-partner-idstring 32 required partner id x-request-idstring 32 required request identifier randomly generated uuid string path parameters cc2string 2 required country code cc2 from send card state card idstring 32 required wallet card identifier granted from partners portal template idstring 32 required approved notification template identifier from partners portal payload ndatastring required notification object json * this field needs to be encrypted * refer to security for more details * the value of "cty" must be set to "notification" notification object refidsarray of string 100 required unique content identifier defined by the content provider data object required name-value pair for use in notification template [example] post /wltex/cards/12584806754/notifications/12353465344/send /*[headers]*/ authorization bearer eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 /*[payload]*/ { “ndata” “eyjjdhkioijbvvriiiwidmvyi…” } /*[notification object]*/ { "refids" [ "ref-20230304-0003", "ref-20230304-0004" ], "data" { "name" "logan", "place" "samsung wallet" } } [response] type value description http status 200 ok payload n/a [result] http status code description 200 ok success 400 bad request requests requests cannot or will not be processed the request due to something that is perceived to be a client error 401 unauthorized authorization token is invalid or expired 500 internal server error the server encountered an unexpected condition that prevented it from fulfilling the request adding notification templates in general, card notification creation is possible through the ‘wallet partners portal' however, a server api is provided for cases where it is necessary to create a large number of card notifications card notifications created through api can also be checked and managed in the same way on the ‘wallet partners portal' [request] type value description method post url /partner/v1/card/template/{card id}/notification header authorizationstring 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer <credentials>* see json web token x-smcs-partner-idstring 32 required partner id x-request-idstring 32 required request identifier random generated uuid string path parameters card idstring 32 required the wallet card identifier granted through the partner portal * the identifier is needed when updating a specific card template body parameters ntemplateobject required actual payload data in basic json format to establish the communication between partners and samsung wallet this must be in the secure jwt json web token format * see the chapter security for more details payload object typestring 20 required notification type m merchant push, g geo push messagetypestring 20 required purpose of notification s service, m marketing messagedetails[]array of object required container of notification message messagedetails[] languagecodestring 20 required default notification language code,e g en, ko messagedetails[] messagestring 500 required notification message forcesaveynstring 10 optional sets whether to save when harmfulness is detected this must be set to either 'y' or 'n' * default 'n' [example notification template object ] { "type" "m", "messagetype" "s", "messagedetails" [ { "languagecode" "en", "message" "it’s notification message " }] } [example] post /partner/v1/card/template/3hdpejr6qi380/notification [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr /** payload **/] { "ntemplate" "eyjjdhkioijkv1qilcjhbgcioijsinrpbwvzdgftcci6imnyzwf0z…" } [response] type value description http status 200 ok payload harmfulresult harmfulness check result responded as “pass” or “fail” harmfullabels reason for harmfulness detection responded only when harmfulresult is “fail” save indicates whether the forcesaveyn option has been set when set to “y”, it is responded as “force” [200 ok] { "resultcode" "0", "resultmessage" "success", "harmfulresult" "pass" } [200 ok] { "resultcode" "0", "resultmessage" "success", "harmfulresult" "fail", "harmfullabels" "hate,violence" } [200 ok] { "resultcode" "0", "resultmessage" "success", "save" "force", "harmfulresult" "fail", "harmfullabels" "violence" } [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable get notification templates [request] type value description method get url /partner/v1/card/template/{card id}/notification headers authorizationstring 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer <credentials>* see json web token x-smcs-partner-idstring 32 required partner id x-request-idstring 32 required request identifier random generated uuid string path parameters card idstring 32 required the wallet card identifier granted through the partner portal * the identifier is needed when updating a specific card template [example] get /partner/v1/card/template/3hdpejr6qi380/notification [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr [response] type value description http status 200 ok [200 ok] { "resultcode" "0", "resultmessage" "success", "templates" [ { "id" "4091356465432138240", "type" "m", "messagetype" "s", "approval" "approved", "messagedetails" [ { "languagecode" "en", "message" "hi! {{name}}, this is merchant push " } ] }, { "id" "4092425423713135680", "type" "m", "messagetype" "s", "approval" "none", "messagedetails" [ { "languagecode" "en", "message" " hi! {{name}}, this is merchant push" } ] }, ] } [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable get notification statistics [request] type value description method get url /partner/v1/card/template/{card id}/stats/notifications headers authorizationstring 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer <credentials>* see json web token x-smcs-partner-idstring 32 required partner id x-request-idstring 32 required request identifier random generated uuid string path parameters card idstring 32 required the wallet card identifier granted through the partner portal * the identifier is needed when updating a specific card template query parameters notificationidstring 32 optional if specified, statistics are returned only for the specified notification if not specified, aggregated statistics for all notifications of the card are returned starttimetamp ms required start date unix timestamp in milliseconds endtimestamp ms required end date unix timestamp in milliseconds metricstring 32 required metric impression click [example] get /partner/v1/card/template/3hdpejr6qi380/stats/notifications?notificationid=123456789&start=1764514800000&end=1765465200000&metric=impression [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr [response] type value description http status 200 ok [200 ok] { "resultcode" "0", "resultmessage" "success", "statistics" [ [ 1764820800000, 1 ], [ 1764896400000, 2 ], [ 1764900000000, 1 ], [ 1764903600000, 0 ], [ 1764907200000, 1 ], [ 1765134000000, 0 ] ] } [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable
tutorials
blogin a previous blog article, we learned about samsung wallet’s server notification api and how to use this api to receive server notifications about samsung wallet card updates in a user’s samsung galaxy devices. this time, we look at the partner server api called “get card data” and how partners can use this api in order to add, update, or cancel issued wallet cards in user’s devices. prerequisites the prerequisites needed for this article are similar to those for our previous article about samsung wallet server apis. namely, we require a partner server where we can set up the get card data api endpoint. in order to set up and test this api, you need to: complete the samsung wallet onboarding process. create a samsung wallet card template. launch the wallet card template and have it in either the verifying or active status so that the card can be added to a user’s device. have an existing server to set up the get card data api endpoint. you can use codesandbox or a similar online hosting service for testing. configure your firewall (if you use any) to accept incoming connections from the samsung wallet server (34.200.172.231 and 13.209.93.60). when you have completed all the prerequisites, proceed to the next step to configure your wallet card template to send requests to your server. setting up the get card data api in the samsung wallet partners portal, open the desired wallet card template and then edit it to set the following “get” field: go to the wallet partners portal. from the wallet cards dropdown, select “manage wallet card.” click the name of the wallet card you want to edit. click “edit” and then scroll down to the “partner get card data” section to modify the partner server url. click “save” to set the server url for the card. get card data api specification for a complete description of the get card data api specification, please check the samsung wallet documentation. method: the get card data api uses a get method to fetch card information from the server. api path: the api path for the request is fixed and uses the “partner get card data” server url that you configured in the previous section. the samsung wallet server sends the get request to this exact url whenever it needs to fetch card data from the partner server. the format for the api path url for the complete get card data request is: {partner server url}/cards/{cardid}/{refid} if the samsung wallet server needs to fetch specific fields from the card data instead of the entire card, then it uses the additional query parameter named “fields” at the end of the url: {partner server url}/cards/{cardid}/{refid}?fields={fields} request header: the samsung wallet server includes 2 fields in the header when calling the get card data endpoint: authorization and x-request-id. an authorization bearer token is provided in the authorization field, so that the partner can verify the request before providing the data. request payload: the request does not contain any payload. expected response payload: the response to the get card data request must contain the card data in one of the following two formats: plain card data in the raw json format. encrypted card data in the cdata format. when the fields query parameter is used in the request url, the card data returned in the response can provide only the fields included in the request. however, it is acceptable to return the entire card data in the response as well. implementing the get card data api we will extend the spring server from the previous article to create the get card data api endpoint. in the api, we need to do 2 things: verify the incoming request to check that it is authentic and actually coming from the samsung wallet server. send the requested card’s data back as the response. the verification part is similar to the verification steps performed in the previous article. the request header contains the authorization bearer token, which we can use to verify the request. after verification, it is necessary to send back valid card data in the response to this get request. we can return either the plain card data or encrypt and tokenize it into cdata. in this implementation, we return the plain card data in the json format. in this example, we use a raw json file from a plaintext file called ticket_ref-001.json for simplicity. the complete get card data api implementation will therefore be as follows: @restcontroller @requestmapping("/cards") class carddatacontroller { // data transmit link @getmapping(path = ["/{cardid}/{refid}"]) fun providecarddata(@pathvariable cardid: string, @pathvariable refid: string, @requestparam("fields", defaultvalue = "") fields: string, @requestheader("authorization") authtoken: string, @requestheader("x-request-id") requestid: string,): string { if(verifyauthtoken(authtoken)){ return jwtgen.getplaincarddata() } else{ return httpstatus.unauthorized.tostring() } } } next, define the getplaincarddata() function, where the cdata is generated using the data provided in the ticket_ref-001.json file. fun getplaincarddata():string{ val data:string = getstringfromfile("sample/payload/ticket_ref-001.json") return data } warningalways verify the authenticity of the get card data request before returning the data in response. the authenticity of the request can be verified using the authorization token provided in the request header. adding cards to samsung wallet using data fetch link once you have configured the get card data api for your server, you can use the api to add cards to the user’s device directly. this is called the data fetch link and unlike the standard approach, it is not necessary to send the card information in the cdata format. instead, you can simply provide the user with the url and they can then add the card to their device by clicking the url. the url format for adding card data is as follows: https://a.swallet.link/atw/v3/{certificateid}/{cardid}#clip?pdata={pdata} so, for example, if your certificateid is a123, cardid is 3h844abcdefg00, and refid is ref-001, then the slim api url for the add to wallet operation is: https://a.swallet.link/atw/v3/a123/3h844abcdefg00#clip?pdata=ref-001 to add the card to their wallet using this method, the user needs to simply visit this url from their device. once the user clicks the link, the samsung wallet server requests the card data from the previously configured get card data api and adds the wallet card to the device. notethe only information required to add a card to the device is the pdata (also known as refid). ensure that this value is a unique hash identifier so that it cannot be easily compromised by third parties figure 1: adding a card to the wallet using data fetch link updating card data using an update notification samsung wallet allows partners to update any issued card’s data using the previously configured get card data api. the card data can be updated in one of the following two ways: the card data is refreshed automatically every time the user opens the card in the detail view. the card data update is triggered manually when the partner sends an update notification. in this case, the card data is updated even when samsung wallet is running in the background, and it is not necessary to open the card in the detail view. when an update notification is sent, the state of the card is immediately updated on the device. afterwards, when the user opens samsung wallet in their device, the card data attributes are refreshed by calling the get card data api. this ensures that the wallet card data is always updated right before the user views it. in order to update card data manually and notify the user about the change, we need to configure the changes in the card data and then send an update notification to the samsung wallet server. once the update notification api is called following the specification, the card’s status and data are updated on the user’s device automatically. samsung wallet uses the refid as the unique identifier of samsung wallet cards. therefore, the refid of the specific card must be included in the payload of the update notification request in order to update the card. the complete specification for the update notification api can be found in the documentation: method: post api path: the request needs to be sent at:{samsung wallet server domain url}/{cc2}/wltex/cards/{cardid}/updates for the samsung wallet server domain url, we can either use the public domain (https://tsapi-card.walletsvc.samsung.com) or the private domain we received in our api callback. request header: the header must contain the authorization, x-smcs-partner-id, and x-request-id request header fields. the samsung wallet server uses this header information to verify the authenticity of the request. additionally, the header also needs to specify the content-type header, which must be set to application/json. request payload: the payload of the update notification must contain the card type, refid, and the new state of the card. optionally, the payload can also contain the fields to be updated so that only those specific fields are retrieved and updated. the payload must be in the following json format: { "card": { "type": "{card type}", "data": [ { "refid": "{ref id}", "state": "{update/deleted/expired}", "fields": "{fields, comma-separated, optional}" } ] } } steps for using the update notification: configure the authorization token. prepare the card data in your server for updating. prepare the header and payload with the refid of the selected card for updating. send the post request to the samsung wallet server for updating. once you send the update notification post request following the specification, the samsung wallet server updates the card on the user’s device. let us modify the data of the previously added card from our server and then call the update notification api. configuring the authorization token all samsung wallet server apis require the use of a bearer authorization token in order to ensure the security and authenticity of the request. you can find the complete specification of the authorization token required by samsung wallet in the documentation the authorization token generation process is very similar to generating cdata, except that for cdata, the payload needs to be encrypted first. for the authorization token, the payload is in plaintext and only contains the api path for verification. to create the bearer authorization token: configure the json payload that describes the method and api path of the request. configure a custom jws header following the jwt format specification. create a jws object using the payload and custom jws header. sign and validate the complete jws object with your partner private and public keys using the rs256 asymmetric algorithm. the complete function to generate the authorization token is given below: fun generateauthorizationtoken(): string{ val payload:string = getstringfromfile("sample/payload/api_path.json") .replace("{refid}", refid) .replace("{method}","get") .replace("{path}","/wltex/cards/cardid/updates/") val jwsalg = jwsalgorithm.rs256 val utc = system.currenttimemillis() val jwsheader = jwsheader.builder(jwsalg) .contenttype("auth") .customparam("partnerid", partner_id) .customparam("certificateid", "a123") .customparam("ver", "3") .customparam("utc", utc) .build() val jwsobj = jwsobject(jwsheader, payload(payload)) val rsajwk = rsakey.builder(partnerpublickey as rsapublickey) .privatekey(partnerprivatekey) .build() val signer: jwssigner try { signer = rsassasigner(rsajwk) jwsobj.sign(signer) } catch (e: joseexception) { e.printstacktrace() } return jwsobj.serialize() } preparing card data for update once the update notification is sent, the samsung wallet server queries the get card data api endpoint for the updated card data and then updates the wallet card with the latest data provided by the api. so before calling the update notification, make sure the card data provided by the api is up-to-date. for our example, let us change the value of the seatnumber field from a-07 to e-05 before calling the update notification api. prepare the request header and payload for the update notification the post request header contains the following fields: authorization, x-smcs-partner-id, and x-request-id. for our example, we set our partner id as the x-smcs-partner-id, a randomly generated code as x-request-id, and generate a bearer token following the authorization token generation process mentioned previously and use it as the authorization field value. next, we set the json payload, according to the previously mentioned format: { "card": { "type": "ticket", "data": [ { "refid": "ref-001", "state": "updated" } ] } } since the fields field is optional, we have omitted it in this example. sending the update notification to the samsung wallet server once everything is ready, we send the update notification post request to the samsung wallet server. we can use any method to send the request, such as postman, curl, or a plain http request. make sure that the update notification is sent immediately after generating the authorization token, as the token only has a ttl (time to live) of 30 seconds. once the update notification is sent, the user should immediately receive a “card information updated” push notification informing them of the card update. afterwards, the next time the user opens the samsung wallet application, the card details are up-to-date and the user can see their new seat number in their card. figure 2: updating card data using an update notification cancelling an event using a cancel notification there are times when you might need to cancel an event and recall all the issued wallet cards for it. in such case, samsung wallet makes it possible to cancel all issued cards with a specific eventid and send a notification regarding the cancelation to all users with the cards associated with the event. therefore, it is no longer necessary to modify issued cards one-by-one using their refid. instead the card issuer can cancel all cards under the event at one time. the process of sending a cancel notification is the same as the update notification process, except for the following differences: the payload needs to contain the eventid instead of the refid the state must always be canceled the post request endpoint url is:{samsung wallet server domain url}/{cc2}/wltex/cards/{cardid}/cancels you can find the complete specification for the cancel notification api in the samsung wallet documentation. now let us send a cancel notification following the same process as update notification: configure the authorization token. prepare the payload with the eventid for cancellation. send the post request to the samsung wallet server for cancellation. for our example, we add a few cards with the same event id to our wallet in different devices, then send a cancel notification following the specification. once the cancel notification is sent, all samsung wallet cards with the given eventid are deleted automatically from all devices and the affected users receive a "ticket canceled" push notification. figure 3: canceling an event using a cancel notification conclusion in this article, we have learned how to configure our server to use the get card data api, as well as how to use various samsung wallet server apis to add, update, delete, and cancel samsung wallet cards from user devices. if you have any further queries regarding this process, feel free to reach out to us through the samsung developers forum.
Mobassir Ahsan
tutorials web
blogthe previous tutorial, implementing "add to wallet" in an android application, showed how to generate and sign a card data token to add the card to samsung wallet. this tutorial demonstrates how you can perform server interactions with the samsung wallet server and retrieve information such as the card states on a user’s device. if you are a samsung wallet partner who is offering samsung wallet cards to your users, you might also want to know how you can track a provided wallet card’s status on a user’s device. follow along in this tutorial to learn how you can utilize the send card state api and retrieve this information to your own server. all code examples used in this tutorial can be found within the sample code provided at the end of this tutorial for further reference. card states and the send card state api the samsung wallet card’s status on a user’s device is represented by various states, such as added, updated, or deleted. whenever the card state of a card changes on a user’s device, samsung wallet server sends a notification to the configured partner server informing about the change. this api provided by samsung is called the send card state api. figure 1: samsung wallet card state changes samsung provides the send card state api as a means of server-to-server communication between the samsung server and the partner’s server and to let the partner know about the card state of their issued cards on user’s devices. with this api, partners can track the state of a wallet card on a user’s samsung galaxy device. prerequisites before you can test the send card state api, you need to: complete the samsung wallet onboarding process. create a samsung wallet card template. launch the wallet card template and have it in verifying or active status so that the card can be added to a user’s device. have an existing server to receive the notifications. you can use codesandbox or a similar online hosting service for testing. configure your firewall (if you use any) to accept incoming connections from the samsung wallet server (34.200.172.231 and 13.209.93.60). when you have completed all the prerequisites, proceed to the next step to configure your wallet card template to send requests to your server. configure the wallet card template for the send card state api to receive the send card state notifications on your server, you need to set your server’s url in the desired samsung wallet card’s options: go to the wallet partners portal. from the wallet cards dropdown, select “manage wallet card.” click the name of the wallet card. click “edit” and then scroll down to the “partner send card state” section to modify the partner server url. click “save” to set the partner server url for the card. figure 2: partner send card state url input field now, whenever a user adds or deletes an issued samsung wallet card to their device, the samsung wallet server automatically sends a post notification to the partner server url set in the wallet partners portal. next you need to learn about the specification of the request so that you can handle it from the server. send card state api specification and format for a complete description of the send card state api specification, see samsung wallet documentation. request method the send card state api uses a post method to send a request to the server. the api path for the request is fixed and uses the partner server url that you defined in section “configure the wallet card template for the send card state api.” api path and url parameters the api path at the very end of the "partner send card state" section is the path where the samsung server sends the send card state post request. so the complete api path url is: {partner server url}/cards/{cardid}/{refid}?cc2={cc2}&event={event}. here, cardid is the card id of the wallet card template and refid is the reference id field of the issued card data, which is a unique identifier. the cc2 query parameter is the 2-letter country code (iso 3166-1 alpha-2) and event is the card state event (added, deleted, or updated) occurring in the user’s device. consider the following example card configuration: partner server url: https://partner.server.url card id: 123 ref id for the issued card: abc country code: us in this configuration, whenever the user adds the card to their samsung wallet application, the samsung wallet server sends a send card state notification to the following url: https://partner.server.url/cards/123/abc?cc2=us&event=added. similarly, if a user from the united kingdom deletes a card with the refid xyz, the post request is sent to https://partner.server.url/cards/123/xyz?cc2=gb&event=deleted. therefore, you can know if a card was added or removed from the user’s device directly from the query parameters. post request body the post request body does not contain any information regarding the card state. rather it just provides a callback url that you can use if you want to send an update notification for the card. { "callback": "https://us-tsapi.walletsvc.samsung.com" } post request header the post request header contains all the required information for ensuring the authenticity of the request. it contains a request id with the name “x-request-id” and a jwt bearer token credential for authentication with the name “authorization” in the header. the samsung wallet server uses a bearer authorization token to ensure the authenticity of the requests being sent to the partner server. for details of the security factors, see authorization token. the bearer token is encoded in base64 following the jwt specification. it has three parts: jws header containing authentication related information, jws payload containing the api path, method, and refid, and jws signature, which validates that the bearer token is signed by the samsung server. jws header format: { "cty": "auth", // always “auth” "ver": "3", // can also be “2” for legacy card data token "partnerid": "4048012345678938963", // your partner id "utc": 1728995805104, // time of signing in milliseconds "alg": "rs256", "certificateid": "a123" // only provided for token version 3 } jws payload format: { "api": { "path": "/cards/3h844qgbhil00/2e19cd17-1b3e-4a3a-b904?cc2=gb&event=added", "method": "post" }, "refid": "2e19cd17-1b3e-4a3a-b904-f30dc91ac264" } finally, the bearer token contains a signature to verify the token. this is signed using the samsung private key and can be validated using the public key provided by samsung wallet during the onboarding process. after receiving any request from the samsung wallet server, your server should send back an http status code as a response. samsung server expects one of the following codes as a response: 200 ok 401 unauthorized 500 internal server error 503 service unavailable this is the complete specification of the send card state api that you need to be aware of before you implement the server. next, you need to configure your server to accept the post request in the specified format. configure the spring server to receive the post request to receive and interpret the send card state post notifications sent by the samsung wallet server, you need to configure a partner server and host the server at the url you specified earlier. to receive the post requests, this tutorial extends an existing server created using the spring boot framework. if you want to know how the spring server is configured, check out the “generate signed wallet card data” section in the implementing "add to wallet" in an android application tutorial. this cdata generation server is used as the base server application for this tutorial, so the dependencies are the same as well. now you can start implementing the tutorial. create a controller class to intercept the post request samsung wallet always sends the send card state post notification to the fixed api path url: {partner server url}/cards/{cardid}/{refid}. create a new controller class in your spring server to intercept any post request that is sent to this api path. @restcontroller @requestmapping("/cards") class cardstatecontroller { @postmapping(path = ["/{cardid}/{refid}"]) fun handlecardstate(@pathvariable cardid: string, @pathvariable refid: string): httpstatuscode { // implement your logic here to process the card state. println("received card state notification for card id $cardid and reference id $refid.") return httpstatus.ok } } run the server and then add or delete a card from your samsung wallet. if the partner server url was set correctly in section “configure the wallet card template for the send card state api,” your server should receive a post request from the samsung server and print the following message to the console: “received card state notification.” update the controller class to receive the query parameters handle the query parameters from the request by adding the following parameters as the function’s parameters: @requestparam("cc2") cc2: string, @requestparam("event") event: string receive and print the request body using the @requestbody body: string parameter. the function should now look like this: @postmapping(path = ["/{cardid}/{refid}"], params = ["cc2", "event"]) fun handlecardstate(@pathvariable cardid: string, @pathvariable refid: string, @requestparam("cc2") cc2: string, @requestparam("event") event: string, @requestbody body: string): httpstatuscode { // implement your logic here to process the card state. println("country code: $cc2") println("wallet card state event: $event") println("request body: $body") return httpstatus.ok } now whenever the samsung server sends a request to the server, it prints the device’s country code and the wallet card’s state event on the device. verify the post request this is the final and the most important step of this tutorial. before accepting any incoming post request, you should always validate the request by following the api specification mentioned earlier in the tutorial. the security procedures can include but are not limited to: matching your partnerid with the received partnerid custom parameter. checking the token version with the ver custom parameter. for token version 3, match your certificateid using the certificateid custom parameter. checking the time of signing using the utc custom parameter. matching the other jws header parameters with the values mentioned in the specification. matching the path from the jws payload with the received url. verifying the jwt. this section shows how you can implement each of these one by one. first, parse the authentication token and read the header. val signedjwt : signedjwt = signedjwt.parse(authtoken) val jwsheader : jwsheader = signedjwt.header match partnerid and jws header parameters: val ownpartnerid = "4048012345678938963" // your partner id from samsung wallet partner portal val receivedpartnerid = jwsheader.customparams["partnerid"] val ctype = jwsheader.contenttype val alg = jwsheader.algorithm.name // check if the jws header parameters match the expected values if (ctype == "auth" && alg == "rs256" && receivedpartnerid == ownpartnerid ) { println("jws header parameters matched") // proceed with further verification } check the token version and match certificateid: val ver = jwsheader.customparams["ver"] val owncertificateid = "a123" // your certificate id from samsung wallet partner portal val receivedcertificateid = jwsheader.customparams["certificateid"]?: "" // if partner uses token version 3 in the jws header of the cdata, // then samsung server also returns version 3 response along with the certificate id if(ver == "3" && receivedcertificateid == owncertificateid){ println("jws header certificate id matched") // proceed with further verification } check if the token was generated recently: // check if the timestamp is within acceptable range val utc = jwsheader.customparams["utc"] as long val timedelta = system.currenttimemillis() - utc println("time delta: $timedelta") if (timedelta < 600000l) { println("utc timestamp is within last 1 minute. time delta = $timedelta ms.") // proceed with further verification } match the api path with the received api path from the payload: val receivedapivalue = signedjwt.payload.tojsonobject()["api"]?.tostring()?: "" val receivedapipath = receivedapivalue.substring(6, receivedapivalue.length - 14) val expectedpath = "/cards/$cardid/$refid?cc2=$cc2&event=$event" // match the path in the payload with the expected path if (receivedapipath == expectedpath) { println("path matched") // proceed with further verification } finally, validate the token using the samsung certificate provided to you during the onboarding process: read the samsung certificate from a file and then extract the public key. for instructions, refer to the cdata generation server sample code at implementing "add to wallet" in an android application. build an rsakey object using the extracted public key. create an rsassaverifier object with the rsakey to verify the token. verify the token using the verifier. // verify the signature of the jwt token using the public key provided by samsung wallet. val samsungpublickey = readcertificate(getstringfromfile("sample/securities/samsung.crt")) val rsakey = rsakey.builder(samsungpublickey as rsapublickey).build() val verifier: rsassaverifier = rsassaverifier(rsakey) if(signedjwt.verify(verifier)){ println("verification successful") // implement your logic here to process the card state notification. // for example, you can update the card status in your database or trigger a notification to the user. // in this example, we simply return a 200 ok response indicating that the notification was successfully processed. return httpstatus.ok } else { println("verification failed") // return an appropriate http status code indicating that the notification could not be verified. return httpstatus.unauthorized } now the complete implementation of the controller class to receive and verify the send card state request is complete. once a send card state request is completely verified, you can accept the request as a valid card state update and make any changes as required. for example, you can update the card status information in your own database or trigger a notification to the user. summary by completing this tutorial, you are now able to receive card state updates from the samsung wallet server using the send card state api and validate them. in a future tutorial, we will discuss how you can expand the server interaction functionality even further and how you can update samsung wallet card information on user devices through the get card data api. if you want to discuss or ask questions about this tutorial, you can share your thoughts or queries on the samsung developers forum or contact us directly for any implementation-related issues through the samsung developer support portal. if you want to keep up-to-date with the latest developments in the samsung developers ecosystem, subscribe to the samsung developers newsletter. sample code you can click on the link given below to download the complete sample code used in this tutorial. wallet card state server sample code (55 kb) dec 2024 additional resources implementing "add to wallet" in an android application send card state authorization token iso 3166 country codes
Mobassir Ahsan
Develop Samsung Wallet
docmanage wallet card the samsung wallet partners portal provides partners with the necessary tools and functionality to integrate the “add to samsung wallet” feature into their services this guide outlines the process of registering, managing wallet cards, and ensuring that everything runs smoothly refer to the partner onboarding guide for the samsung wallet portal the partners need to complete the following steps to register and gain access to the samsung wallet portal note-wallet portal currently offers 'add to samsung wallet' functionality to the partners overall managing process once registered and logged into the samsung wallet portal, partners can follow the steps to manage wallet cards and monitor performance step 1 - create wallet card template begin by drafting the cards that will be added to samsung wallet these cards can include loyalty cards, tickets, boarding passes, and more draft status - initially, these cards will be in draft status until they are fully configured and ready for testing manage wallet card partners can manage all registered wallet cards this includes edit, update, and monitor the status of the wallet cards general information the general information page allows the partner to enter administrative details to manage their cards, as well as to define common parameters for the wallet folder contents testing mode all data generated in testing mode is periodically deleted be sure to turn off the "testing mode" setting after the test is over wallet card name representative title of the wallet card wallet card id unique wallet card domain name partner app package name partner application package name wallet card template pre-defined partner wallet card template partner get card data url for the partner api call to receive card data if the partner uses this api, enter the url otherwise leave it blank partner send card state url for the partner api call to send a card state notification if the partner uses this api, enter the url otherwise leave it blank samsung server ips samsung wallet server ips which need to be allowed by the partner’s firewall, separately described for inbound and outbound wearable wallet assistance whether to support the wearable wallet service support ‘no network’ status whether to support wallet card opening during the ‘no network’ status description description of the wallet card select card template the samsung wallet portal offers various wallet card templates optimized for different use cases, including boarding passes, tickets, coupons, and digital ids to streamline your integration, you can easily select the appropriate template from the select wallet card template pop-up window steps to select wallet card template navigate to the select wallet card template option within the portal in the wallet card type drop-down menu, select the category that best suits your use case e g , boarding pass, ticket, coupon, or digital id once the card type is selected, a list of templates will appear in the wallet card sub type section choose one of the available templates from the list that corresponds to your selected card type some card types support a flexible layout design after selecting the template, you can proceed with configuring the card’s details, including the branding, content, and data fields specific to the selected template samsung wallet supports various wallet card types designed to cater to different use cases each card type is optimized for specific functions, making it easier for partners to provide a seamless experience to users note-refer to section wallet card type to learn more about it view wallet card template partners can easily manage all their registered wallet cards through the samsung wallet portal this includes the ability to view, edit, and delete wallet cards as needed step 2 - launch wallet card template verifying status once a wallet card is ready for launch, it must go through the verifying status before it can be activated and made available to users partners can launch and activate their cards once they have been reviewed and approved, ensuring the card meets all requirements steps to launch card template to begin the launch process, click yes to confirm and approve the activation of the wallet card to begin the activation process, click the launch button for the card you wish to activate once a card is launched, the button text changes to launched the activation cannot be cancelled after the card is launched, its status will change to verifying during this stage, the system will conduct a final review to ensure all information is accurate and meets the necessary requirements after verification, the card will undergo administrator approval the admin will review and approve the card for activation once the card is approved by the administrator, its status will change to active, making it available for users to add to their samsung wallet launch wallet card template rejected status if the wallet card is rejected after launching, you can modify the card and re-launch steps to modify the card and re-launch the administrator registers the reason for rejection when rejecting the launched wallet card it is sent to the partner by email from the system, including the reason for rejection partners can apply for launch again by checking the reason for rejection and modifying the wallet card information step 3 – testing mode partners can use the testing mode to test a wallet card internally before it is officially released to users this feature ensures that all aspects of the card, including its functionality and user experience, are working as expected when you create a new wallet card, the testing mode option is enabled by default, allowing you to perform internal tests without affecting user access all data generated during testing is periodically deleted to ensure that no test data remains in the system once testing is complete even though testing mode is enabled, the card is still visible and accessible in the system testing does not prevent the card from being exposed to users, so you can verify its functionality without any restrictions once testing is complete and you are satisfied with the card’s performance, be sure to turn off testing mode note-remember to change the status from testing mode on to testing mode off to finalize the testing process and prepare the card for official release step 4 - admin approval active status after a wallet card is launched, it must go through an administrator approval process before it becomes active and visible to users steps for admin approval once the launch button is clicked, the card’s status automatically changes to verifying during this stage, the card is reviewed for accuracy, completeness, and compliance with samsung wallet requirements note-please ensure that testing is completed using either your own implementation or the add to wallet test tool, as the samsung wallet administrator will verify the results through server-side test logs an administrator will review the submitted wallet card to ensure it meets all content and technical guidelines if the card passes the review, it is approved for activation upon administrator approval, the card status updates 'active' once the card reaches active status, it becomes visible and accessible to end users, enabling them to add it to their wallets step 5 – add to samsung wallet integration to integrate the "add to samsung wallet" feature into your system, you need to insert the appropriate "add to wallet" script this script is available for various platforms, including web, android, and email/mms, and each platform requires a slightly different implementation approach follow the steps below to successfully implement the "add to wallet" button create the tokenized card data, known as cdata, which contains the actual wallet card content note-since cdata has a time-to-live ttl of 30 seconds, it is recommended that the system generates cdata in real time to ensure it remains valid when processed 2 the cdata format varies depending on the card type e g , loyalty card, ticket, coupon 3 refer to the [_cdata generation sample code_][cdata generation sample code] on the partners portal for detailed guidance 4 copy the sample **‘add to wallet’** script from [_partners portal’s wallet card_][partners portal’s wallet card] page 5 replace the placeholder "cdata" in the script with your generated tokenized card data 6 apply the script to your system see [_partners portal’s wallet card_][partners portal’s wallet card] for details note-for "add to wallet" integration, you may need some base data you can find that and other necessary information on partners portal and wallet api spec you can also add image beacon in the script for tracking effect analysis add to wallet script guide step 6 – merchant push notification partners can create a message template for sending pushes on each of their wallet cards type partners can only choose the merchant push type message type you can choose a message type from marketing or others rejected comment if the merchant push notification is rejected after request approval, you can modify the message template the administrator registers the reason for rejection when rejecting the merchant push notification it is sent to the partner by email from the system, including the reason for rejection partners can request for approval again by checking the reason for rejection and modifying the message template approved date displays the date and time when the push message is approved by the administrator message template you can create the contents of the push, and it is also possible to put the available variables in '{{}}' after configuring the content, click harmfulness verification to verify whether there is a harmful expression in the content the verified result is displayed as pass or fail, and if it is fail, it shows the filtered harmful expression together even if the verified result is fail, an approval request can be made, but it can be rejected by the administrator if a different language is added to the default language in general information, the message template must also be entered for each added language request approval button after completing the message template, click this button to send an e-mail requesting approval to the administrator configure the wallet card layout samsung wallet offers the flexibility to customize card layouts according to your preferences samsung wallet supports 2 different layout types while all cards can use the default layout type, the flexible layout type is only available for specific cards this section defines the design and attributes of the wallet cards to be supported through the flexible layout type supported card types with flexible layout the card types that support the flexible layout type are as follows loyalty membership , coupon, event ticket, generic card, boarding pass create a card with flexible layout when creating a wallet card that supports the flexible layout type, the user can choose between the default and flexible layouts when selecting the card type to create a wallet card with a flexible layout create a wallet card select the wallet card template to use select the type and sub type for the wallet card template selecting a card type that supports a flexible layout will display the available flexible layout identifiable by the name 'generic-subtypename-default' note-please choose carefully, as the layout type cannot be changed once the card is activated card design and attribute configuration step 1 determine the layout preset to determine the layout preset in the template editor, click the preset change button to modify the layout design presets consist of a combination of three areas card header area, card primary area, and card auxiliary area select each tabs respectively to create the desired combination note-the design types provided vary by card type and area note-• changing the preset updates all previously saved layouts • once a card has been activated, its layout cannot be modified ensure thorough testing before releasing the card card header area choose from six option, including logo type and sub-text combinations logo type logo image, logo image + text, text only the card header area has the same configuration across all card types, and 6 available configurations card primary area the main section that determines the card's primary layout the card primary area is configured differently for each card types the primary area of loyalty membership , coupon, event ticket, generic card has 7 available configurations the primary area of a boarding pass has 4 available configurations card auxiliary area select the number of text fields needed to provide additional information the card auxiliary area is configured differently for each card types the auxiliary area of loyalty membership ,, coupon, event ticket, generic card has 5 available configurations the auxiliary area of a boarding pass has 6 available configurations step 2 define key values for each attribute in the layout to define the key values for each attribute click on an empty container in the card preview where the key has not been set when an empty container consists of a label and a value pair, the label and value are selected as a group setting either a label or a value synchronizes and applies the values across all grouped containers click the entry key button to view the supported attribute names please refer to the wallet card spec for details on the attributes of each entry key boarding pass | event ticket | coupon | loyalty membership | generic card select an attribute from the list or if the desired attribute is not available, enter the value directly in the direct input field when selecting from the attribute list, samsung wallet's supported text will appear in your application save the key value by clicking the save button once all configurations are complete, click apply to implement the layout step 3 prepare card data matching the layout design to prepare the card data matching the chosen layout design refer to the specifications for each card type for wallet card data if you used direct input during layout setup, provide an extendedfields attribute corresponding to the key value entrykey the key entered in the input field label the name displayed in your application value the data corresponding to the label "extendedfields" "[{\"label\" \"group/boarding\", \"value\" \"6/10 35\", \"entrykey\" \"group/boarding\"}]"
Learn Code Lab
codelabutilize the add to samsung wallet service for digital cards notescenes in the demo video are simulated and does not represent any real-world conditions or outcomes objective learn how to use the add to samsung wallet service so that users can store digital contents, such as boarding passes, tickets, and coupons, to their samsung wallet app partnership request to create, manage, and monitor performance of wallet cards with the samsung wallet partners site, you must become an official samsung partner once done, you can fully utilize this code lab you can learn more by visiting samsung wallet partner onboarding process, here in samsung developers overview samsung wallet is an application that securely stores essential items such as boarding passes, tickets, and coupons, making them easily accessible from anywhere with this app, users can access various partner wallet cards in one place, simply by swiping up from the bottom of the screen the add to samsung wallet service provides interfaces for users to conveniently add digital content to samsung wallet here are examples of the supported wallet cards boarding pass journey information such as flights, trains, and buses can be provided as notifications, allowing easy retrieval when checking in by configuring server synchronization, updates to journey information such as gate changes, schedule changes, or cancellations can be received by the users ticket notifications about events and additional information, including benefits, can be provided based on real-time utilization of performances, sports games, movies, and admission tickets, status updates related to expiration and availability can be provided gift card gift card, also referred to as a prepaid card, provides real-time balance and transaction history loyalty loyalty cards function as membership credentials, managing membership information through these cards, loyalty points can be administered and redeemed id id cards can fulfill identification verification purposes, such as identity cards, employee cards, and licenses physical documents can be represented through wallet cards, and near field communication nfc -based authentication can be provided reservation reservation cards can contain diverse online booking details, including rental cars, restaurants, and accommodations ongoing reservation information can be managed as a journey pay as you go pay as you go cards allow users to register services that can be charged and utilized according to their preference for convenient use generic card generic cards enable users to create customized cards by selecting preferred card template layouts and designing elements notedepending on your country or region, some card types are not supported if you need assistance, please contact us at samsung dev support the image below shows the process of managing wallet cards for more information, refer to manage wallet cards set up your environment you will need the following latest version of samsung wallet app from galaxy store samsung galaxy device that supports samsung wallet access to samsung wallet partners site internet browser, such as chrome openssl intellij idea or any java ide optional start the onboarding process partners can manage wallet cards and monitor performance with the samsung wallet partners site to join as partner generate a private key and certificate signing request csr using the openssl command you can follow the instructions in security factors notea private key enables encryption and is the most important component of certificates while csr, which is a necessary factor to obtain a signed certificate, includes the public key and additional information like organization and country proceed to register in the samsung wallet partners site using your samsung account follow the samsung wallet partner onboarding process upload the generated csr for data encryption in encryption setting management section after registration, you will receive a welcome email noteupon receiving the certificates via email, be sure to keep the information safe from exposure and only use them for the following purposes signed certificate used along with the private key to sign data samsung certificate used to encrypt card data and validate authentication tokens in server api headers create a wallet card follow the steps below to create a wallet card in samsung wallet partners site click the wallet cards menu and choose create wallet card fill out the general information form with the details of the wallet card in wallet card template, choose a card type and sub type select the design type and click done you can choose from various types of wallet card templates optimized for partners after inputting all necessary details, click save to set the wallet card status to draft launch the wallet card you can launch and request activation of the card by clicking the launch button upon agreeing to proceed, the launch button text changes to launched and the card status becomes verifying add the card to samsung wallet using the test tool open a web browser on your computer or galaxy mobile device, and go to the following link partner walletsvc samsung com/addtowallettest go to add to wallet tab and click choose key file to upload your private key in the select card dropdown menu, select the created card to display the card details and populate sample data navigate to the form tab and modify the card data as desired notethe structure for configuring wallet cards follows the defined specification you can refer to the full list of card-specific attributes specification scroll down to the bottom of the page and click the add to samsung wallet button click done when a preview of the card shows on your mobile screen with a message indicating that the card has been added to your wallet once the card is added to your samsung wallet app, you can check its details by clicking on it noteyou can also go to the playground tab and add cards to the samsung wallet app even without creating a card on the wallet partners site update the status of the added card if a server api info partner get card data and partner send card state is registered in the wallet card, real-time updates of the user's registered cards can be provided notefor more information, see server interaction modify and update the card's status by utilizing the push notification feature of the test tool navigate to the push notification tab ensure that the correct private key is uploaded and the same card as in the add to wallet tab is selected copy the ref id value from the add to wallet tab and paste it into ref id field in the push notification tab in the status field, enter one of the following card states expired, redeemed, held, suspended, or deleted the current state is set to active then, click the request push notification button check the card in the samsung wallet app to confirm the change tokenize card data and implement the add to samsung wallet button to your service optional notethis step is optional, but if you want to learn how to integrate the add to samsung wallet button into your services like an android app, web app, or email, you can follow these steps the samsung wallet partners site provides generated add to samsung wallet scripts for each wallet card you create you can simply copy and paste these scripts into your partner apps web and android or include them in emails/mms messages to implement the add to wallet button, follow these steps go to the [add to wallet script guide] section of the card you created click show to view the available scripts and then copy the appropriate script for your service develop a program that can generate tokenized card data cdata the cdata represents the actual content of the wallet card and comes in different formats depending on the card type you can check the cdata generation sample code for reference the cdata is derived from the card data, which is in json format for testing purposes, you can utilize the generated json from the test tool follow the implementing atw button guide to determine where to incorporate the generated cdata and gain further insights into this process you're done! congratulations! you have successfully achieved the goal of this code lab topic now, you can utilize the add to samsung wallet service by yourself! to learn more, explore samsung wallet
Develop Samsung Wallet
doccard management api guidelines once your service is successfully onboarded, you gain the ability to design and deploy custom digital assets—such as boarding passes, coupons, tickets, and more—directly to samsung wallet the adding samsung wallet card templates section defines interfaces for providers to conveniently create wallet cards in samsung wallet the generated wallet card templates can be updated by following the instructions on the updating wallet card templates section authorized partners can add wallet cards to users directly from the partner server by following the instructions on the adding wallet cards section below service domain environment domain public domain https //tsapi-card walletsvc samsung com adding wallet card templates this section describes how to create a wallet card in samsung wallet [request] type value description method post url /partner/v1/card/template headers authorization string 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer <credentials>* see json web token x-smcs-partner-id string 32 required partner id x-request-id string 32 required request identifier random generated uuid string body parameters ctemplate object required actual payload data in basic json format to establish the communication between partners and samsung wallet this must be in the secure jwt json web token format * see the chapter security for more details payload object titlestring 32 required wallet card name countrycodestring 2 required the main headquarters location code refer to iso-3166-1 alpha-2 for the country code cardtypestring 100 required template card typefor details, refer to wallet cards subtypestring 100 required template card sub typefor details, refer to wallet cards designtypestring 100 optional the value that definesthe design type of the wallet card for details, refer to wallet cards applogoimgstring 200 optional the banner logo image url the maximum size of the image is 1024*1024 e g ttp //www yourdomain com/banner_logo_image png saveinserverynstring 1 optional sets whether to save the card data this value can only be set for the ‘id card’ type prtnrapppckgnamestring 128 optional the application package name nonetworksupportynstring 1 optional sets whether to support opening the wallet card under 'no network' status this feature cannot be modified after the wallet card is approved this must be set to either 'y' or 'n' * default 'n' sharebuttonexposureynstring 1 optional sets whether to support the sharing function this feature cannot be modified after the wallet card is approved this must be set to either 'y' or 'n' * default 'y' privacymodeynstring 1 optional if this value is set, the user authentication is required when using the card to protect the user's sensitive information this must be set to either 'y' or 'n' * default 'n' preventcaptureynstring 1 optional this value is a screen capture prevention flag that defines whether the content view prevents screen capture categorystring 20 optional this item can only be set if the card type is “generic” set the category to get more detailed statistical information for instance, parking pass, membership, reservations, insurance, health, receipt, coupon stamp, note, photo, and others prtnrcarddatastring 1000 optional [get card data] partner url check the url format below and implement the api according to the url refer to partner server api specification for instance, you can use https //yourdomain prtnrcardstatestring 1000 optional [get card state] partner url check the url format below and implement api according to url refer to partner server api specification for instance, you can use https //yourdomain prtnrmempointstring 1000 optional [get membership point] partner url cardmetacpstring 1000 optional [get card meta cp] partner url getfulfillmentliststring 1000 optional [get fulfillment list] partner url prtnrbalancestring 1000 optional [get card balance] partner url statestring 15 optional when creating a card, you can transition the card's state from “draft” to “verifying” you can only choose “draft” or “verifying” * default 'draft' descstring 500 optional description example /** example card template object **/ { "title" "coupon", "countrycode" "kr", "cardtype" "coupon", "subtype" "others", "nonetworksupportyn" "n", "sharebuttonexposureyn" "y" } /** example **/ post /partner/v1/card/template [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr /** payload **/ { "ctemplate" "eyjjdhkioijkv1qilcjhbgcioijsinrpbwvzdgftcci6imnyzwf0z…" } [response] type value description http status 200 ok payload cardid wallet card id [example] 200 ok { "cardid" "3hdpejr6qi380", "resultcode" "0", "resultmessage" "success" } [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable updating wallet card templates wallet card templates updated through api can also be checked and managed in the same way on the ‘wallet partners portal' partners can manage all wallet cards they have created [request] type value description method post url /partner/v1/card/template/{card id} headers authorization string 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer <credentials>* see json web token x-smcs-partner-id string 32 required partner id x-request-id string 32 required request identifier random generated uuid string path parameters card id string 32 required the wallet card identifier granted through the partner portal * the identifier is needed when updating a specific card template body parameters ctemplate object required actual payload data in basic json format to establish the communication between partners and samsung wallet this must be in the secure jwt json web token format * see the chapter security for more details payload object titlestring 32 required wallet card name countrycodestring 2 optional the main headquarters location code refer to iso-3166-1 alpha-2 for the country code prtnrapppckgnamestring 128 optional the application package name applogoimgstring 200 optional the banner logo image url the maximum size of that image is 1024*1024 saveinserverynstring 1 optional sets whether to save the card data this value can only be set for the ‘id card’ type nonetworksupportynstring 1 optional sets whether to support opening the wallet card under 'no network' status this feature cannot be modified after the wallet card is approved this must be set to either 'y' or 'n' * default 'n' sharebuttonexposureynstring 1 optional sets whether to support the sharing function this feature cannot be modified after the wallet card is approved this must be set to either 'y' or 'n' * default 'y' privacymodeynstring 1 optional if this value is set, user authentication is required when using the card to protect the user's sensitive information this must be set to either 'y' or 'n' * default 'n' preventcaptureynstring 1 optional this value is a screen capture prevention flag that defines whether the content view prevents screen capture categorystring 20 optional this item can only be set if the card type is “generic” set the category to get more detailed statistical information for instance parking pass, membership, reservations, insurance, health, receipt, coupon stamp, note, photo, and others prtnrcarddatastring 1000 optional [get card data] partner url check the url format below and implement the api according to the url refer to partner server api specification for instance, you can use https //yourdomainn prtnrcardstatestring 1000 optional partner url check the url format below and implement the api according to the url refer to partner server api specification for instance, you can use https //yourdomain prtnrmempointstring 1000 optional [get membership point] partner url cardmetacpstring 1000 optional [get card meta cp] partner url getfulfillmentliststring 1000 optional [get fulfillmet list] partner url prtnrbalancestring 1000 optional [get card balance] partner url statestring 15 optional if the card status is “draft”, you can only select “verifying” testingmodeoffstring 1 optional this value can be set only when the card status is active normal service is possible only when the testing mode is changed to off * default ‘n’ descstring 500 optional description [example] /* *example card template object **/ { "title" "coupon", "countrycode" "kr", "nonetworksupportyn" "n", "sharebuttonexposureyn" "y" } /** example **/ post /partner/v1/card/template/cardid=3hdpejr6qi380 [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr /** payload **/ { "ctemplate" "eyjjdhkioijkv1qilcjhbgcioijsinrpbwvzdgftcci6imnyzwf0z…" } [response] type value description http status 200 ok payload cardid wallet card id [example] 200 ok { "cardid" "3hdpejr6qi380", "resultcode" "0", "resultmessage" "success" } [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable get wallet card templates wallet card templates created through the api can be retrieved via the template list api and are also visible and manageable through the wallet partners portal partners can view and manage all wallet card templates they have created [request] type value description method get url /partner/v1/card/templates headers authorizationstring 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer * see json web token x-smcs-partner-idstring 32 required partner id x-request-idstring 32 required request identifier random generated uuid string [example] /** example **/ get /partner/v1/card/templates [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr [response] type value description http status 200 ok [example] 200 ok { "resultcode" "0", "resultmessage" "success", "templates" [ { "cardid" "3hdpejr6qi380", "title" "wallet card title 01", "countrycode" "us", "cardtype" "loyalty", "subtype" "others", "nonetworksupportyn" "n", "testingmodeoff" "y", "provisioningtype" "na", "usemoreserviceyn" "n", "preventcaptureyn" "n", "prtnrapppckgname" null, "privacymodeyn" "n", "sharebuttonexposureyn" "y", "state" "verifying", "applogoimg" “”, "desc" “” }, { "cardid" "3ctei2riqi9iq", "title" "wallet card title 02", "countrycode" "us", "cardtype" "generic", "subtype" "others", "nonetworksupportyn" "n", "testingmodeoff" "y", "provisioningtype" "na", "usemoreserviceyn" "n", "preventcaptureyn" "n", "prtnrapppckgname" “”, "privacymodeyn" "n", "state" "verifying", "category" "membership", "applogoimg" “”, "desc" "ntf_us_generic" } ] } [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable adding wallet cards a typical addition to the wallet card is triggered by user interaction, such as pressing the add to wallet button or link the api also supports adding a wallet card automatically to the user for a special purpose with user’s consent this api allows partners to provide wallet cards to users the request payload must contain information about the target to which the card is added this information may be related to the user’s account, or it may contain information about a card that is already registered a push notification is sent to the user’s device to confirm successful card registration the success of card registration must be determined that the card is registered normally when it is updated to added of send card state an administrator must grant permission for partners to use this api card data specification card id {card id} is an id issued when the partner manager signs up for partner services and register the wallet card they want to service refer to partner onboarding guide document for details cdata actual payload data in basic json format to establish the communication between partners and samsung wallet see the details in the table below card data token the specific wallet card data mentioned as cdata must be secured in jwt json web token format see a chapter security for details [request] type value description method post url /atw/v1/cards/{card id} headers authorization string 1024 required credential token the token can have prefix "bearer" as an authorization type i e , bearer <credentials>* see json web token x-smcs-partner-id string 32 required partner id x-request-id string 32 required request identifier random generated uuid string path parameters card id string 32 required wallet card identifier granted through the partner portal body parameters cdata object required actual payload data in basic json format to establish the communication between partners and samsung wallet this must be in the secure jwt json web token format * see the chapter security for more details payload object card object required wallet card object card type string 16 required wallet card type *see wallet cards card subtype string 16 required wallet card sub type *see wallet cards card data[] array of object required wallet card data container data[] refid string 32 required a unique content identifier defined by the content provider data[] createdat long 13 required data creation timestamp epoch timestamp in milliseconds *utc±00 00 data[] updatedat long 13 required data update timestamp epoch timestamp in milliseconds *utc±00 00 data[] language string 8 required default card language code e g en, ko data[] attributes object required attributes container data[] attributes {fields} required attributes fields by card type*see wallet cards data[] localization[] array of object optional localized language container *see wallet cards localization[] language string 8 required multilingual content language code, e g en, ko localization[] attributes {fields} for displaying a given language, ‘data[] attributes’ can be replaced by localized versions *see wallet cards account object conditional user account object account type string 16 required type of user identifier, e g phonenumber, email account value string 64 required user identifier [example] /** example card object **/ { "card" { "type" "ticket", "subtype" "movies", "data" [{ "refid" "ref-20230304-001", "createdat" 1612660039000, "language" "en", "attributes" { "title" "samsung wallet", "mainimg" "https // /main png" *refer to wallet cards }, "localization" [{ "language" "ko", "attributes" { "title" "삼성 월렛" } }] }] }, "account" { "type" "phonenumber", "value" "+821012345678” } } /** example **/ post /atw/v1/cards/1656147182764415319 [headers] authorization eyjjdhkioijbvvriiiwidmvyijoxlcjwyxj0bmvyswqioiixmjg1o x-smcs-partner-id partner-id-0001 x-request-id req-202303140003 x-request-cc2 kr /** payload **/ { "cdata" "eyjjdhkioijkv1qilcjhbgcioijsinrpbwvzdgftcci6imnyzwf0z…" } [response] type value description http status 200 ok payload n/a example 200 ok [result] http status code description 200 200 ok 400 400 bad request requests cannot or will not be processed the request due to something that is perceived to be a client error 401 401 unauthorized authorization token is invalid or expired 500 500 internal server error 503 503 service unavailable
Develop Samsung Wallet
docoverview this section describes the add to samsung wallet process, which enables partners to register cards in samsung wallet and define their baseline data, presentation, and capabilities add to wallet is the standard and mandatory process for publishing wallet cards the lifecycle, portal operations, and rest apis described in this section apply to all supported card types most card services rely solely on the add to wallet process and do not require any additional feature integration scope add to samsung wallet defines card registration and lifecycle management template configuration and publication card metadata, layout, and action data definition capability declaration, including optional nfc support the behaviors and state transitions described in this section represent the canonical integration path for wallet cards optional feature extensions some card programs may support additional device-level capabilities beyond standard card presentation where applicable, such features are treated as optional extensions to the base add to wallet process detailed technical and operational requirements for those extensions are described in separate documentation service flow the add to samsung wallet atw service provides a set of interfaces that enable users to easily add digital content to their samsung wallet, enhancing convenience by allowing users to store, manage, and access items such as loyalty cards, tickets, boarding passes, and more directly within the app the service involves several steps, from content preparation to updates and managing card states preparation steps to prepare the contents intended to store on samsung wallet must be tokenized as jwt json web token when using data transmit link considering what environments, the button will be displayed in such as app, web, mms, or email when you plan to integrate this service refer to implement the button section for more details note-the data transmit link is used for communication between the partner’s server and samsung wallet this link sends any additional information related to the card such as updates or notifications about the card’s status add to wallet steps to add to wallet once users who want to store contents click or tab the linked button, it initiates the process of adding to samsung wallet if you are providing the full pass content, use the data transmit link option note-the data fetch link enables the partner's backend system to pull content dynamically when a user clicks the "add to wallet" button, the system fetches the necessary content e g , card details, event data, loyalty points using this link samsung will notify the result through server interface named send card state send card event this works as a callback for 'add to wallet' process delivering events and country code for the user wallet card to handle interactions after storing content in samsung wallet, server interfaces are required these interfaces are defined in the updating wallet card specs see api guidelines for more details update wallet cards steps to update wallet cards partners may need to update or modify the content stored in samsung wallet for example, a user might accumulate more loyalty points, or flight details may change to update the wallet card content, partners must call the samsung server api the cc2 path parameter must match the cc2 value from the send card state send card event api notification triggered by the added event refer to samsung server api section for more details update notification is for single content cancel notification is for calling off every user's wallet card content related to a specific event get card data payload has the same format of card information as the one of 'add to wallet' send card state send card event can also have an event 'deleted' to notify a wallet card deletion on samsung wallet by users gift cards and generic cards currently do not support update notification functionality card states wallet cards within samsung wallet can have various states e g , active, expired, used, suspended for each content provider’s notifications and user actions the state diagram below describes wallet card states from beginning to end state diagram
Develop Samsung Wallet
docintroduction welcome to the samsung wallet cards integration guide samsung wallet is a secure and unified digital wallet solution designed for samsung galaxy devices, offering users a convenient way to store and manage a wide range of digital assets—including payment cards, loyalty memberships, travel tickets, coupons, digital ids, and more seamlessly integrated with samsung’s ecosystem, it enables contactless payments via samsung pay, supports biometric authentication for enhanced security, and allows for real-time interactions like push notifications and location-based reminders samsung wallet empowers partners and developers to deliver personalized, digital-first experiences while ensuring user data remains private and protected samsung wallet is an e-wallet service that allows users of samsung devices to securely store and access various digital items, such as credit cards, boarding passes, loyalty cards, and digital keys by combining multiple services into one platform, it streamlines everyday transactions and digital storage in a convenient and user-friendly interface users can add their ticket, coupon, boarding pass, and other types of data into samsung wallet using an add to wallet link via multiple online channels like app, web, e-mail, or social media messages benefits of samsung wallet cards service this document provides an overview for integration partners looking to enable digital items e g , tickets, coupons, and passes on samsung wallet this guide will walk you through the setup, onboarding, implementation, and management steps needed to launch your wallet-enabled services this document describes how to implement samsung wallet cards service features from the integration partner's point of view a partner account is a samsung developer account registered on the samsung wallet partners portal it allows samsung wallet partners to manage their wallet services, register card templates, access credentials partner id, card id , and communicate securely with samsung’s servers to integrate with samsung wallet cards, partners follow a structured process that enables their digital content—such as tickets, coupons, and passes—to be stored and managed in the samsung wallet app the implementation includes the following stages partner account setup to begin, the integration partner must create a samsung account and register as a service provider in the samsung wallet partners portal this account grants access to tools and resources needed for integration, including card management, api credentials, and documentation onboarding during onboarding, the partner submits basic company details, once submitted, samsung issues the following key integration credentials partner id card id certificates for secure communication via a signed csr these credentials are required for card generation, secure api calls, and managing wallet content add to samsung wallet integration the partner integrates the "add to samsung wallet" functionality into their digital platforms—such as apps, websites, or emails—by adding a button or link when end users click the button, the link triggers the process of creating and storing a digital card in samsung wallet partners can deliver content in two ways data transmit link encodes card content directly in a jwt json web token data fetch link samsung fetches the content from a partner's server upon user action each card is uniquely identified by a reference id refid reusing the same id updates the card silently wallet card management after cards are added to users' samsung wallet apps, the partner can manage them by interacting with samsung’s server apis this includes updating card content e g , time changes, status updates sending notifications for specific events cancelling or deleting cards receiving events via the send card state callback e g , when a user adds or removes a card these server-to-server communications ensure cards stay current and reflect real-time changes
We use cookies to improve your experience on our website and to show you relevant advertising. Manage you settings for our cookies below.
These cookies are essential as they enable you to move around the website. This category cannot be disabled.
These cookies collect information about how you use our website. for example which pages you visit most often. All information these cookies collect is used to improve how the website works.
These cookies allow our website to remember choices you make (such as your user name, language or the region your are in) and tailor the website to provide enhanced features and content for you.
You have successfully updated your cookie preferences.