I'm currently looking into Cybersource's REST API for the tokenization of cards.
Reference: https://developer.cybersource.com/api-reference-assets/index.html#token-management
However, I'm having some trouble wrapping my head around the following and could use some advice from those who have already worked with Cybersource and are more familiar with the terminology.
Under Token Management, there's an Instrument Identifier and Payment Instrument.
Instrument Identifier seems to return the same unique ID for the same card and is part of the overall Payment Instrument token.
If I POST (create) a Payment Instrument token, inside the response, I see that as well, where an Instrument Identifier is returned and giving me back the same id as long as the card is the same.
However, the Payment Instrument always returns a new token.
Question:
I'm trying to think of Payment Instrument as a payment method, tokenizing a card, and not per payment, but since it returns a different token each time even if I put in the same credit card, am I understanding this wrong? Should I treat the Payment Instrument as something else completely different?
If I were to store a token on our side, which one would I be?
As for payments API, we can pass in a token, does this work for both types mentioned above?
Any help, guidance or thoughts are appreciated
Cybersource is never good at API design or documentation. but their document on this topic could help you understand the concept
https://developer.cybersource.com/api/developer-guides/dita-tms/paymentInstrumentREST.html
Look at the first chart.
A "customer" has a "payment instrument" which associates with a "card", which could have multiple instrument identifiers that each has one-on-one mapping with a specific card number.
This model exists because consumer can have the SAME card updated with different card numbers OR expire date. ("Payment Instrument" tries to represent the "SAMEness" part of it.)
So Cybersource's "Payment Instrument" model can be seen as an "abstract" card object/container representing the working "instrument" (that is why it doesn't store the number) which knows the actual card number that should be used (but the merchant doesn't necessary need to know), in the mean time, it knows the "history" of the card.
The naming is terrible, the "Payment Instrument" itself has an ID, then Instrument Identifier ID is an "ID" too (guess the guy who came up with the name forgot ID is the acronym for "Identifier"? LOL). Very confusing indeed. Just keep in mind that Instrument Identifier ID maps to a card number, "Payment Instrument" ID is a container that maps to a series of (SAME) card numbers (potentially)
So that answers your question why you can get a different "Payment Instrument" ID every time, because you can think of it as different merchant has a different "Payment Instrument" ID for the same customer with that physical card. As long as Cybersource has the record and knows how to find the associated instrument identifier ID via this "Payment Instrument ID", it is mission accomplished.
Again you know Cybersource is a dinosaur living in the past, so you have to deal with it
So my understanding of how this works, is that a payment instrument is a TYPE of payment (ACH, CreditCard, bitcoin, ApplePay™, GooglePay™, etc.) then the instrument identifier is the token (or id) that represents the specific account number within that payment type.
So a payment instrument of Credit Card might have an instrument identifier of Visa account 4242424242424242 but the Token Management Service (TMS) returns an instrument identifier of AA7D990C34583376EB05345443E0234242434B. The TMS allows for relevant information to then be stored within a CUSTOMER identifier (which is the "wallet" owner). As the TMS becomes more feature rich, the addition of things like 'shipping info' and other possible 'preferences' may become available. The other concept is that this digital wallet (TMS token API) can have its permissions granted to other merchant entities so that all payment processing and transactions can be managed through one (OMNICHANEL) API and this payment information can remain SECURE, AUDITABLE, GRANTED, REVOKED, etc.
Now the reason you can get different "tokens" for the same instrument is based on preference. This means that if a cardholder doesn't want to 'keep payment info on file' or 'store the token for later use'. Then the TMS system will provide a token for one-time use, thereby satisfying the requirement of the merchant (reducing PCI scope/risks) and keeping the preference of the cardholder.
This is in no way an official explanation, so I am definitely open to any additional insights on how TMS (from Cybersource™) is designed to work.
Related
I am using Google Analytics 4 (GA4) on the client to track a whole bunch of different events. However, there are 2 scenarios that I can't cover client side:
A user completing check out on a payment page hosted by a third-party (Stripe in this case).
A refund that is made by the support team.
These events are handled by the server using webhooks. To me it seems like the most straightforward solution, would be to let the server send the event to GA4 (as opposed to the client sending it). I believe the Measurement Protocol should be used for this.
For each event submitted through the Measurement Protocol a client_id is required. When the client is submitting an event, this is an automatically generated ID which is used to track a particular device.
My question thus is, what should the client_id be when submitting an event server-side?
Should the same client_id perhaps be used for all events, as to recognize the server as one device? I have read some people proposing to use a randomly generated client_id for each event, but this would result in a new user to be recognized for every server-side event...
EDIT:
One of the answers proposes to use the client_id, which is part of the request as a cookie. However, for both examples given above, this cookie is not present as the request is made by a third-party webhook and not by the user.
I could of course store the client_id in the DB, but the refund in the second example is given by the support team. And thus conceptually it feels odd to associate that event with the user's client_id as the client_id is just a way to recognize the user's device? I.e. it is not the user's device which triggered the refund event here.
Another refund event example would be when user A makes a purchase with user B and user B refunds this purchase a week later. In this situation, should the client_id be the one of user A or of user B? Again, it feels odd to use a stored client_id here. Because, what if user A is logged in on two devices? Which client_id should be used here then?
Great question. Yes, your aim to use Measurement Protocol is a proper solution here.
Do not hardcode the client id. It's gonna be a hellish mess in reports. The nature of user-based reporting (which GA is) demands client ids to uniquely identify users. To your best ability.
GA stores the client id in a cookie. You should have convenient and immediate access to it on every client hit to BE. The cookie name is _ga. GA4 appends the measurement id to the cookie name. Here, google's docs on it: https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage But you can easily find it if you inspect "collect" hits and look at their payloads. There's another cookie named _gid that contains a different value. That would be a unique client id. Set it too if you can, but don't use it for the normal client id. It has a different purpose. Here how the cookie looks here, on stack:
And here it is in Network. You will need it for proper debugging. Mostly to make sure your FE client ids are the same as BE client ids:
Keep an eye on the cases when the cookie is not set. When a cookie is not set, that most frequently means the user is using an ad-blocker. Your analysts will still want to know that the transaction happened even if there's a lack of context about the user. You still can track them properly.
3.1 The laziest solution would be giving them an "AnonymousUser" client id and then append a random number to that so that it would
both indicate that a user is anonymous and still make it possible
for GA to separate them.
3.2 A better solution would be for you to make a fingerprint client id for such users, say, hashing a concatenated string of their
useragent+ip+locale+screen resolution, this is up to your analysts
to actually work on the definition of a unique user if the google
analytics library is unable to do it.
3.3 Finally, one of the best solutions for you would be generating a client id on your own, keeping GA's format and maybe adding an indicator there that it has been generated on your end just for easier debugging in the Future and setting it as a cookie, using it instead of _ga. Just use a different cookie name so that ad-blockers wouldn't know to block it.
If you want to indicate that a hit was sent through the server, that's a good idea. Use custom dimension for that. Just sync it with your analysts first. Maybe they wouldn't want that, or maybe they would want it in a different dimension.
Now, this is very trivial. There are ways to go much deeper and to improve the quality of data from here. Like gluing the order id, the transaction id, the user id to that, using them to generate client id, do some custom client tracking for the future. But I must say that it's better than what more than 90% of, say, shopify clients have.
Also, GA4 is not good enough for deeper production usage. Many things there are still very rudimentary and lacking. I would suggest concentrating on Universal Analytics and having GA4 as a backup for when Google makes GA4 actually good enough to replace UA. That is, unless you're downloading your data elsewhere and not using GA's interface for analysis.
It seems that this page (Relevant portion in the screenshot below), advices to either send the data along with the client_id or user_id. However fails to address the fact client_id is a mandatory field as stated here.
I believe it is probably safe to assume that randomly generating this field should work. At least it seems to on my end however be warned that I am unsure if this has any impact on attribution.
* In the above image, Device ID refers to client_id
I want to create a smart contract and launch it for ICO. I also create a website where people can buy my token. I want know how to check how many token been sold (live)? so i can create a live bar counter to show how many percentages of the token already been sold.
Or is there a way i can monitor the token sale process in the smart contract?
A token contract is no different than any other smart contract. There are no special built in Solidity features or logic associated with them. They are just regular smart contracts that follow a specification.
So, if you want access to the number of tokens sold, you code that into your contract. While tokens sold is not part of the standard ERC20/ERC721 interface, nothing prevents you from adding a constant function to retrieve this information. In fact, if you're using the basic Zeppelin Crowdsale contract, you can just calculate it using the public state variables weiRaised / rate (Chances are you should be creating your own Crowdsale subcontract, so it's better to add the functionality you want there).
We can use the Etherscan Developer API to review transactions against a given contract address and find out the total supply or number of items available for sale.
There is a lot you can do with the Etherscan Developer API. For example, here's one URL that pulls data from Ethereum Mainnet -> Etherscan -> JSON parser -> Shields.io and renders it as an image to calculate the number of Su Squares remaining for sale:
Source: https://img.shields.io/badge/dynamic/json.svg?label=Su+Squares+available&url=https%3A%2F%2Fapi.etherscan.io%2Fapi%3Fmodule%3Daccount%26action%3Dtokenbalance%26contractaddress%3D0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F%26address%3D0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F%26tag%3Dlatest%26apikey%3DYourApiKeyToken&query=%24.result
^ I don't know if SO is going to cache the image here. But that URL is a live URL which pulls the number of Su Squares available hot off the blockchain.
We're creating a flow for boarding new customers and would like to use the enhanced ecommerce tracking of universal analytics to track the boarding steps.
A single applicant fills in a form supplying information about their business and delivery addresses and such. The problem is that after the application has been submitted, the applicants need to electronically sign an agreement. There can be multiple people signing, and the person signing therefor doesn't necessarily need to be the same person that filled in the application. Is it possible to track a flow where another user/session takes over and finalizes the application?
If all participants in the application process sign in with a token - same token for all - you can set it as userID and enable session stitching - you'll need special userID view (and update your privacy policy) which will only show visits for which the userID was set and will recognize users across multiple computers, devices etc.
However this will still give you aggregated data only, so if you want to track individual users in addition to the flow you have to set the userID as a custom dimension (talk to your lawyer first, even with an anonymous ID profile building might be a privacy issue). The userID must contain nothing that would allow anybody but your own company to identify a specific user or device (no e-mail-addresses, no MAC addresses etc). Then you can pull the individual data with the custom dimension as key and match it with your CRM data.
No guarantees, but that seems the closest you can get to your requirements using GA.
I am creating a Recurring payment profile using Direct payment(credit card details entered during registration are not stored in database). I want to update/change the bill amount for every bill cycle(because billing is done per user per month).
I am using UpdateRecurringPaymentsProfileDetails API method to change the amount, but the method needs credit card details again(for each time it is called). I am getting the credit card details using GetRecurringPaymentsProfileDetails, but this method just returns the last 4 digits of credit card(and does not return CVV2, but this is not major issue here).
Is there any other option to get the full credit card details(at least credit card number) using Paypal APIs or should I have to store credit card numbers in my database? Any help would be highly appreciated.
It's unlikely that you'll be able to get the full credit card number from PayPal; that's why people use PayPal.
Storing credit card information in your database is a huge liability, and should be avoided if at all possible. Once you start storing that information, your company is responsible for keeping that information secure (and that includes developers). Use another third party component if you must, but don't take on such an enormous liability.
I don't know what company you work for, but that's not a decision that a developer should be making on their own. Entire companies have been shut down for mishandling credit card information. The law around that stuff is extremely murky, and even the smallest mistake can result in massive fines.
I have implemented few payment websites using PayPal Standard, PayPal Website Pro, PayPal Express and Authorize.Net.
Now I'm implementing a website which requires recurring billing. My only problem is variable amount, since I do not store credit card information, and amount is not fixed in each cycle.
Can we use either PayPal or Authorize.Net for my project? If not, could you please recommend any reliable payment gateway ($US for payment, and gateway located in US please) for that matter?
You can use a service like Authorize.Net's Customer Information Manager (CIM) to store the credit card and billing information for you and then you create your own scheduling engine that charges against the payment method you have stored for them using CIM. CIM also allows you to make off-cycle payments at any time as well.
Well the variable amount to bill shouldn't be a problem if you can put together whatever formula would be used in code. However if you aren't storing the actual credit card info (and I can understand why), then I don't see how you'd be able to charge the customer every month. Normally you need a credit card or bank information to do a direct transfer.
If you absolutely cannot store the information, then the only thing I can imagine is putting together an automated calculation and notification system that can send the customer an email with a link that brings them to a form so they can enter the information as simply as possible. Otherwise you'll need to save their credit card info somewhere secure and simply bill them every month, which isn't uncommon.
Have you looked into PayPal's IPN variables?
https://www.paypal.com/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside
Typically you have to cancel then reapprove a new subscription... but perhaps you can use the variables some how to do that programmatically.
I found a solution. PayPal calls ProcessReferencePayment.
At first, I need to charge the credit card using DoDirectPayment, and store the successful transaction number.
After that, I just call DoReferenceTransaction along with OrderTotal and ReferenceID (the previous transaction number).
DoReferenceTransactionRequestDetailsType
DoReferenceTransactionReq