Visa Developer Community
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Ask the Community
rbrandenburg
Helper
January
1 Kudo
I'm looking these instructions on how to send various API requests. So far, in the sandbox environment, I'm able to successfully generate tokenized payment profiles, authorize credit cards using the payment profile id, and charge credit cards. Everything seems to be working correctly. However, I'm wondering about the following scenario: A customer enters credit card information on our website, including card number and expiration date. The information is used to generate a payment profile. However, the customer made a mistake and entered the wrong expiration date. In order to correct the mistake, the customer edits the infomation they entered and updates the expiration date to be correct. What should happen in this situation? Which (if any) of the following options are available? Send a request to the API to update (not generate) the payment profile, using the payment profile ID. Note that I will not be able to include the credit card number in the request, because it will not be accessible on my end at this point. Determine the expiration date through an API that can verify it with the payment processor to ensure the date is correct. (This correction would happen upon trying to generate the payment profile.) Only update the expiration date on my end, and include it in the request the next time the customer tries to make a purchase and I authorize the credit card. (In this case, I am specifically wondering whether the authorization request will actually update the expiration date stored in the payment profile on CyberSource's end.) If none of these are an option, can I just treat it as a "new" payment profile generation request and store the returned profile id on the card, discarding the previous one? Or will this generation request fail since a profile already exists for this card number? (I can determine this through testing, but it's not a high priority since I consider this option a last resort.)
... View more
November
I've started investigating this issue again and when I try to contact the V2 endpoint to generate a token, I get a 405 "Method not allowed" error. Do I need to update something on my Visa Developer account to use the V2 API? This also happens when I try to generate v2 keys using the same type of request on this endpoint: https://sandbox.api.visa.com/cybersource/v2/payments/keys What endpoint do I need to contact to get v2 keys and generate v2 payment profiles?
... View more
September
1 Kudo
Thank you. I changed the URL for token generation to v2, but I noticed that when generating keys, the FlexService (from the SDK) is still using an HttpClient with the following v1 URL: https://sandbox.api.visa.com/cybersource/payments/flex/v1/keys I've looked into the documentation and I'm not sure where it gets this URL from-- it seems to have it as soon as I call FlexServiceFactory.createInstance(). Note that this is using new credentials created through my Visa Developer account. Is there something I need to do when creating these credentials to make them correspond to v2, or is there something in the SDK that I'm not seeing which lets me change the URL for generating keys? It looks like the version of the SDK I'm using (0.3.1) is the most recent one: https://search.maven.org/search?q=a:flex-server-sdk Note that I'm not looking to use MicroForm for this phase of implementation. Can you tell me how to get a v2 FlexService using this SDK and/or get credentials that will let me initialize a v2 FlexService? Or will I need to make my own implementation of what the FlexService does?
... View more
September
Yes, I pass in the token via the customer ID field when sending the request. To answer your questions: Here is the request body: (with some information removed for security) RequestBody: {
"clientReferenceInformation" : {
"code" : "6280401"
},
"processingInformation" : {
"capture" : "false",
"authorizationOptions" : {
"authType" : "STANDARDCAPTURE",
"authIndicator" : "0",
"ignoreAvsResult" : "false"
}
},
"orderInformation" : {
"billTo" : {
[address information]
},
"shipTo" : {[address information]}, "amountDetails" : { "totalAmount" : "9.99", "currency" : "USD" } }, "paymentInformation" : { "tokenizedCard" : { "expirationYear" : "2022", "number" : "5366041269806291704107", "securityCode" : "000", "expirationMonth" : "01", "type" : "001", "transactionType" : "1" }, "customer" : { "customerID" : "5366041269806291704107" } }, "recipientInformation" : { "customer" : { "customerID" : "5366041269806291704107" }, "tokenizedCard" : { "expirationYear" : "2022", "number" : "5366041269806291704107", "securityCode" : "000", "expirationMonth" : "01", "type" : "001", "transactionType" : "1" } } } 2. Here is the response body: ResponseBody: {
"clientReferenceInformation" : {
"code" : "6280401"
},
"errorInformation" : {
"reason" : "INVALID_ACCOUNT",
"message" : "Decline - Invalid account number"
},
"id" : "5366041860956333603003",
"status" : "DECLINED",
"_links" : {
"self" : {
"href" : "/pts/v2/payments/5366041860956333603003",
"method" : "GET"
},
"authReversal" : {
"href" : "/pts/v2/payments/5366041860956333603003/reversals",
"method" : "POST"
},
"capture" : {
"href" : "/pts/v2/payments/5366041860956333603003/captures",
"method" : "POST"
},
"refund" : {
"href" : "/pts/v2/payments/5366041860956333603003/refunds",
"method" : "POST"
},
"void" : {
"href" : "/pts/v2/payments/5366041860956333603003/voids",
"method" : "POST"
}
}
} The status code of the response is 201. 3. The request was not generated with a groovy script, but rather via the Visa Developer SDK, following the examples here: https://github.com/visa/SampleCode/tree/master/vdp-java/src/main/java/com/visa/vdp/utils Specifically, I call VisaAPIClient. doXPayTokenRequest() using the endpoint: https://sandbox.api.visa.com/cybersource/v2/payments?apikey={apikey} with the same API key I use to generate tokens. Everything else is handled by the XPayHttpClient. 4. I generate payment tokens using v1of the Secure Acceptance Flex Token API and authorize the card using v2 of the CyberSource Payments REST API, as documented here: https://developer.visa.com/capabilities/cybersource/reference?next=cybersource__cybersource_flex_api#cybersource__cybs_payments_v2
... View more
August
Thanks for the response, but I am still seeing this in the response when I try to authorize using the updated request: "errorInformation" : {
"reason" : "INVALID_ACCOUNT",
"message" : "Decline - Invalid account number"
}, This is using a new token for a new card. To be clear, the value I should be using is "token" from the "tokenize card" response, correct? Also, is it possible the problem is that I'm hitting the v1 endpoint for tokenizing and the v2 endpoint for authorizing the payment? I tried changing the tokenization request endpoint to v2, but it couldn't find it.
... View more
August
1 Kudo
I spent a while looking for documentation for sending a tokenized payment authorization request to the CyberSource payments REST API. The documentation shows all possible request bindings, but I was unable to format a sandbox request which would allow me to authorize a card using the payment token rather than the card number. No matter what I would do, I got this result: "errorInformation" : {
"reason" : "INVALID_ACCOUNT",
"message" : "Decline - Invalid account number"
}, Note that generating a payment profile seems to work fine. I understand that there is a team specifically for handling CyberSource related questions, so I called them, but I was told that the API is in beta, some of the documentation might be missing, and that they were unable to help me. However, it sounded like it should be possible to get the request to succeed, just that there isn't complete documentation for doing so. They also mentioned a "subscriptionID" binding, but I don't see this anywhere in the documentation. Given that the CyberSource help line wasn't able to answer my question and there is no documentation for this specific case, I understand that I may not get an answer here, but just in case, does anyone happen to know how to authorize a card this way? Again, I want to send an authorize request to the API I linked without using the card number, so the example code which uses the card number won't work for my use case. Edit: Looking at my request bindings, paymentInformation > customer > customerId seems like it could be the "invalid account number" the response is referring to. However, I don't see any other binding in the request or response for tokenizing the card that would represent this account number, so it seems like I should just be using the payment profile ID or subscription ID.
... View more
August
1 Kudo
I am using the v2 APIs and they seem to be working for the most part when I test them in a sandbox environment. I am wondering specifically about whether I can send a single "process payment" request and be guaranteed that a "success" response means that the customer was charged the full amount authorized, or whether "success" exclusively refers to the authorization and I need to send a second response either to A) capture the payment or B) verify that the capture from the first request succeeded. Apologies if this is already covered in the documentation of the response bindinngs, but I was unable to find an answer to this question when I read the documentation.
... View more
August
1 Kudo
I was looking over this documentation on processing a payment and looking over the "capture" and "authType" bindings. I'm trying to set up the request so it will both auth and capture, then send a response that indicates whether it authed and captured. I'm not concerned with partial captures, so can I do the following? Set "capture" to true and "authType" to "AUTOCAPTURE" in the request bindings If the response says the transaction was successful, assume that the customer was charged for the amount in the "authorizedAmount" binding of the response If the response says the transaciton was unsuccessful, assume that the customer was not charged I would prefer not to have to send a second request to the "capture" endpoint in cases where I want to capture immediately, since this workflow would be simpler. However, I want to make sure I can safely assume that the customer was charged the "authorized" amount in successful cases and not charged at all in unsuccesful cases.
... View more
July
1 Kudo
Thank you. Does this apply to the secure acceptance flexible token API as well as the Cybersource Payments REST API? On that page, the documentation for the flex token API still shows V1, and when testing again I found that I could no longer tokenize cards whether I was using V1 or V2 or the URI. Should the V1 endpoint still be working for tokenizing? Is there updated documentation for sending a request to the V2 API from a Java application using the Cybersource flex SDK?
... View more
July
1 Kudo
Sorry if this has already been covered in another thread, but I wasn't able to find an answer when I looked. I'm currently working in a sandbox environment and it looks like I can successfully generate FlexPublicKeys and payment profiles. I want to make sure I also set up a workflow for checking for existing keys/profiles before trying to generate them, as well as updating existing payment profiles. I noticed that FlexPublicKey in the CyberSource Flex SDK has a method called "retrieveKey()" which sounds like what I should be using. Specifically, I'm thinking of calling this method when I need a FlexPublicKey for a request, and calling generateKey() if the result is null. Is this an intended/workable use case? What is the String argument that retrieveKey() takes? For payment profiles, I've been working based off example code from this repo and making the request to generate a payment profile using VisaClient.doXPayTokenRequest(). From what I can tell, the identifier that specifies that the request is meant to generate a profile is "tokens" in the resource path, and the endpoint generates a payment profile based on values in the request body and includes the profile id in the response body. Is there a type of request that simply checks whether a profile exists and another that updates an existing profile? Or should I just use the same workflow for both of these cases as for generating a new profile, and build the application in such a way that it doesn't care whether a payment profile exists and always attempts to "generate" one?
... View more
Public Statistics
| Date Registered | May 2018 |
| Date Last Visited | |
| Total Messages Posted | 11 |
| Total Kudos Received | 7 |
Latest Tags
No tags yet