We have a client using Volusion as a storefront/e-commerce solution. We need to export purchase data, including credit card information, from it into a fulfillment provider who will then run a customer's credit card only when/if the item they ordered ships.
We have access to the server running IIS, we have the API on the fulfillment provider side to send this data over HTTPS, and we can build a simple polling ASP.Net app that runs on the same PCI-certified server that holds the CC data that moves data from Volusion to the fulfillment provider securely.
What remains is how to get the data out of Volusion. We've had several answers and none have panned out:
Use the API. The API documentation is very light, and doesn't make clear how to get CC data out.
Fill out a verification form and you can "view" it. This came from their customer service department, but they were very shaky on details.
Query the database directly. It's not clear whether this is feasible.
If someone here has handled external credit card processing on Volusion before, we're interested in how to get this done. What the process is to get these fields enabled in the XML API and the format of those fields would be enough, or some other approach - whatever gets us to the finish line.
I am pretty sure that Volusion will not ever release customer's Credit Card information to you via an API or any other means.
maybe this will help you do more research:
http://devwiki.volusion.com/index.php/Customers_Export
http://devwiki.volusion.com/index.php/Orders_Export - the closest you can get is the last 4 of the CC number.
A better design pattern would be to charge the customer at purchase time, if the drop shipper cannot fulfill the order cancel the order and refund the transaction.
You cannot extract the credit card number through the Volusion API. The only way to do it is contact Volusion Support have them enable the displaying of credit card numbers within your Admin. They will probably have you sign a wavier that you will follow PCI compliance.
Related
I have an ASP.Net website, and am attempting to re-implement our existing PayPal checkout flow (previously based on their Payments Pro product/SOAP APIs) to behave similarly under their Advanced Checkout flow with REST APIs. (PayPal is deprecating fraud filters in Payments Pro and it's forcing the change from a business perspective).
I've reviewed the PayPal v2 REST APIs. PayPal-based checkout is fine (and I have a working flow for it) but can find no means to directly accept credit cards for processing. The closest I've come is to use the PayPal.Net library and attempt to run the card as a FundingInstrument -- but this returns an "PAYEE_ACCOUNT_INVALID" in the Sandbox, even though that account Advanced Credit and Debit box checked in the app settings. I could simply direct all payments to the PayPal main page and let the user choose the funding source from there, but the user experience of doing a Visa payment this way is cumbersome and likely to lead to cart abandonment for users accustomed to simply running their stored Visa card as a method of payment.
The available JavaScript code I've seen appears to render the credit card buttons on the site by calling host code, and effectively executing the transaction entirely on PayPal's servers. If my own Javascript was better, I might be able to figure out the loop of how to stuff in the user's saved details into the rendered buttons, but I'd much prefer some sort of .Net-based solution. Has anyone had any experience building such a thing? Is it even possible in the current REST API?
Any pointers would be much appreciated--never had so much trouble locating sample code or resources for a project, and am starting to wonder if it's simply not supported...
Thanks,
-Pete
The best solution is to use Advanced Credit and Debit Card hosted fields. The CSS of these fields can be customized to match the rest of your site, but the actual number, cvv, expiry date fields are hosted directly by PayPal (in tiny iframes), which frees you from having to do a PCI SAQ-D assessment for that processing.
This does not give a solution cards you've already stored numbers for, however. You could vault all those cards, using the PayPal vault API and then later referencing each vaulted payment token to create orders with them. This way you'll be able to eliminate the storage of actual card information on your systems.
Hoping for a bit of guidance / reassurance on air search and book flow in Sabre (SOAP API) which I'm integrating with for a client website project.
My client is planning to take payment separately via a 3rd party payment gateway and also have a 3rd party ticketing robot.
The details I have been given from the ticketing robot company is that we should create the PNR then queue transfer to "International/Domestic Agent Q50" (with their PCC).
I've got access to and have been reading the Sabre Dev Studio, have access to the Sabre SOAP API (I have my client's credentials and PCC) and have followed the "Low Far Search and Book" workflow here (https://developer.sabre.com/docs/read/workflows/Low_Fare_Search_and_Book) exchanging EnhancedAirBookRQ and PassengerDetailsRQ for CreatePassengerNameRecordRQ as advised on that page and inserting payment before, my proposed work flow is:
Create a token with TokenCreateRQ
Use token to perform a search with BargainFinderMaxRQ
Display results to customer, customer picks an itinerary / flight segments
Collect customer details from customer
External payment gateway take payment for amount returned in BarginFinderMaxRQ
Book the desired flight segments using the orchestrated API CreatePassengerNameRecordRQ, including:
Adding passenger details and flight segments
Specifying that the payment was in cash
Performing the queue transfer?
I've got BargainFinderMaxRQ coded up and working.
I'm starting the integration with CreatePassengerNameRecordRQ and have noticed the price returned can be different to the price returned from BargainFinderMaxRQ. Which makes me question the above work flow. I selected it due to the easier integration (I can use tokens rather than manage a session and it's just one API call).
So, my questions:
Is my understanding correct, is this the correct work flow for the project? Given that my client is taking payment via an external payment gateway and want to display the final figure to the customer before they pay.
I'm struggling to understand how the ticketing robot fits into the process. Hoping for a steer on how that affects the PNR call(s). Do I still set the ticket type to "7TAW" and queue place onto their PCC + queue number?
Thank you for any help, greatly appreciated.
1) Yes, the process is correct, but there are scenarios in which airlines change fares or where the airline does not confirm the availability immediately, so when you price you are actually pricing an IATA fare, which is usually more expensive. For particular scenarios, I recommend you to contact the API support.
2) The "7TAW", which is the ticketing time limit, is meant to have the limit set by the airline until when you can issue the ticket without having the possibility of losing the given price. Some airlines require that to be done on the same day of the booking (which is what you are setting with the 7TAW). Some airlines give you some days and some others can give you just 30 minutes after booking. It is almost impossible for us to respond on how would the robot require this to be provided, so for you to be sure, I would recommend you checking with the owners of that robot and ask them how would they want it, maybe they don't even care.
What is the process of offline payment gateway. I got the one side process from internet.
User will enter first and final 4 digit of credit card and giving cvv code, filling other relevant details then submit.
It will reach to to the admin side, I want to know what is the process happening admin side for receiving and completing the process.
I saw some woocommerce plug in for WordPress, but I didn't clear what is happening in other side.
Thank You
I am going to treat this question as a business logic one more so than a technical one. Based on information provided, I see two possible scenarios:
Scenario One - Storing CC#s for later
You're wanting to collect credit card information to process later via a terminal. Like a POS system inside a store or a web portal where you can type in the information.
This would be very difficult to make compliant with PCI-DSS. The cost of maintaining a PCI complaint system, much less setting it up, tends to be prohibitive except for the largest of companies. You need to use a service, like PayPal, Stripe, Authorize.net, etc etc. Depending on the platform you're developing the website, all major credit card processors should have tools for a simple integration.
Scenario Two - Accepting offline payment methods
This would be a usecase where you want to allow users to pay via mailing a check or some other form of physical payment. This would just mean adapting your shopping / payment experience to allow an option to pay that method, provide a mailing address, and putting a hold on the purchase from processing further until payment is received.
This is what I have based on what was given so far, if I am off base, please elaborate!
I'm starting to use Paypal SDK to implement the payment service for a ASP.NET site. I wrote the code following the SDK example and everything worked fine, of course I'm managing the whole process (credit card data entry and submission included). The site owner however complained about credit card data management and thus asked me to re-implement the whole procedure without managing the credit card data 'internally' at all but leaving Paypal doing this part of the job.
This mean that NO data of the credit card should be entered in forms belonging to the site I'm coding.
As far as I can see (but I'm just a newbie in Paypal SDK) there's not a way to do what I'm asked for using SDK API calls.
Given my lack of experience I'm not sure about what I'm stating then I can only suppose that I'm missing something so... there's a way to do so trough API calls?
Best Regards,
Mike
What your site owner is likely asking you to do is to leverage PayPal's Vault API (part of its REST APIs) to store credit card information so your site doesn't have to. If you store the credit card information on your site, you have to ensure the data is stored in a PCI-compliant manner, which may be too costly for some sites. The Vault API will return a credit card token that can only be used by your REST application for making payments. The API also allows you to get the details of the credit card using the token, but will mask the full credit card number.
There are some examples on how to do this in the PayPal .NET SDK Samples. If there's a use case that's missing, feel free to let us know over on GitHub.
PayPal basics for ASP.net c#
http://www.codeproject.com/Articles/42894/Introduction-to-PayPal-for-C-ASP-NET-developers
http://www.codeproject.com/Questions/718003/How-implement-Strong-cryptography-with-associated
http://forums.asp.net/t/1977404.aspx?Integrate+with+Paypal+account+within+Net+project
http://www.west-wind.com/presentations/PayPalIntegration/PayPalIntegration.asp
I am integrating a payment gateway; this is the first time I am integrating payment gateway functionality to my system, I am using Authorised.Net for the payment gateway.
As I have successfully integrated it but I see the user has to enter the following values to purchase his item, and the transaction id is returned.
//post_values.Add("x_card_num", "4111111111111111");
//post_values.Add("x_card_num", CreditCard);
//post_values.Add("x_exp_date", "0115");
////post_values.Add("x_amount", "19.99");
////post_values.Add("x_amount", );
////post_values.Add("x_description", "Sample Transaction");
//post_values.Add("x_amount", txtAmout.Text);
//post_values.Add("x_description", txtDesc.Text);
////post_values.Add("x_first_name", "John");
////post_values.Add("x_last_name", "Doe");
////post_values.Add("x_address", "1234 Street");
////post_values.Add("x_state", "WA");
////post_values.Add("x_zip", "98004");
//post_values.Add("x_first_name", txtFName.Text);
//post_values.Add("x_last_name", txtFName.Text);
//post_values.Add("x_address", txtAddr.Text);
//post_values.Add("x_state", txtState.Text);
//post_values.Add("x_zip", txtZip.Text);
These values just fix his transaction and purchase of item, so my confusion is that if the web site owner put all this information into his database and made more transactions using his details, then what? Is it safe and secure, or something else happens that I could not figure out?
Here are some basic guidelines to follow:
Keep all information in your database except for the credit number. Never keep the credit number unless you feel that your encryption systems are safe.
Store Authorize.net successful or failed transactions
You need to create a transaction table where you will create a new line for each transaction, regardless of being the same user, or transaction result.
Encrypt some portions of the transaction: Address is good thing to encrypt. This will avoid identity theft if you ever get hacked.
Make sure all user passwords are hashed
Store the Web Site Database connection encrypted as well
Communicate with the database using only stored procedures. This should avoid SQL injection, if the stored procedures are built correctly.
This is how it is, website owner can put all the information into his database, if the transaction mode is present on the website, thats why I and I think most of others either do transactions from trusted sites or sites that redirect to some trusted gateway like paypal or authorize.net for financial transactions.
Thanks for the clarification. I'm currently working on a project that is using PayPal in this same manner. We store only the authorization code and transaction ID in our database.
In my opinion, the 30 seconds or so that the user will save by having their information stored isn't worth the risk associated with storing their information. If you're doing recurring transactions, the vendor will store the information securely for you (at least PayPal does) so there's no real reason to store the credit card information in your system.
[EDIT] As Imran pointed out, storing the last 4 digits of the number would be fine for display on a report.
You can do nothing to prevent the DB owner from misusing the information if they're storing it aside from contacting your credit card company and reporting fraudulent charges. The payment gateway has no idea who is inputting the payment details, other than ensuring the transaction is coming from one of their authorized customers (i.e., the customer authorized to use the payment gateway).