I realize they have an API but some of
the questions I have wouldn't be
answered by it, and it would be great
to receive feedback from others who
have integrated it before.
I basically am working with a web site where visitors may choose to sell a used item to the site owner.
If the user decides to sell, he can enter in the specifications of the item and be given a quote. Then he'll proceed to enter in his address, which I assume I'll have to verify using the Fedex API before or during the part where it creates a shipping label.
So assuming the address is verified, it looks like the script in the API I have to interact with is /Ship/Ground/Domestic/ShipGroundDomestic.php5 ( since we will not integrate any other type of shipment type yet ).
Is this is the script that actually creates the shipment and charges the account setup, assuming all goes well it returns a xml response with the status?
Since it's SOAP based - I realize there are options for a pdf and png shipping label type, it looks like it generates the label but where is it actually stored, is it just temporary?
In the script it specifies options for a API Key, password, account #, and Meter # - so I would have to actually know the site owners credentials, since it charges for creating shipments/labels I can't use a normal account that doesn't have a CC setup, can I?
I can't actually test anything without contacting them and telling them to make my account go into test mode? Or is there an extra parameter for test mode?
I should store all shipments in a local database to pull them up, right? Or should I solely rely on Fedex for storing all the information? If I use a local database I can map shipments to users and use a Fedex provided script to look up the delivery status so I would think I have to do that.
If I were to have a feature that automatically emailed customers with status updates of a delivery, I would have to use some type of cron job to look and see if there were any updates made, I can't do this any other way?
If you are using the the Fedex Web Services API you get a test key by going to https://www.fedex.com/wpor/wpor/editConsult.do
(You may need to be already signed in).
The label it generates it just dumps into the current directory. That is obviously not acceptable for production code, since it does not even generate a unique file name, but the php file is example code. Modify the code they give to do whatever you want with the returned label.
You would want a local database.
Why would you want to send users updates? Is there any reason they cannot just use the tracking number and look it up themselves? I mean it would be possible to call the tracking API periodically and generate emails, but do users really want these emails?
Related
I'm programming the back-end for an ecommerce solution, Bitcoind API gives me one way of sending money to a bitcoin address: sendfrom <fromaccount> <tobitcoinaddress> <amount>
If I understood well, this will transfer money from one account to an address, but I don't see any way of sending from address to address. I didn't implemented accounts on my backend system, and don't want to do it as it's an aditional layer of complexity that I don't want to deal with right now.
So, I supose this will grab money from whatever address/addresses asociated to the account and send them to the bitcoin address provided. Any way of doing what I want to do?
Check getaccount <bitcoinaddress>: "Returns the account associated with the given address." You give it a bitcoin address, receive the corresponding account, and can then use that account to sendfrom.
However, for security reasons, I advise against sending payments directly from PHP running on a web server. You may want to introduce at least one additional layer of validation before actual payment, and that layer is probably running on a separate machine. For example, have PHP write the payment orders to the database for another application elsewhere to poll and process. Both applications will have access to the database, but no direct link between them; and the PHP side will not (have to) be authorized to access the BTC wallet at all. Also consider using hot and cold wallets.
I'm using the Salesforce REST API and found it very hard to find decent documentation.
I can successfully log in with OAuth and i can push new accounts to Salesforce.
I use the instance url to make the API calls and i send the following fields to create an account object:
Name
Rating
Description
The problem is that I created a free trial (which sits on na9.salesforce.com) and everything worked fine.
I created a second free trial to check if everything works with another account, but the rating field is not available... I get the following message from Salesforce:
"[{"message":"No such column 'rating' on sobject of Account"}]"
Why is that?
Also, is it possible to add notes to a created account using POST? And is it possible to create Leads instead of Accounts using the API?
Thanks in advance,
A feature called field level security (FLS) can mean that even standard fields are not accessible, check the FLS settings on account in your second org.
Docs for the REST API are on the developer force site
Been integrating AuthNet's Automated Recurring Billing system alongside its Silent Post feature to create a paid features system inside our team's web app. The silent post feature has slim documentation, but I have come across several helpful threads on SO as well as a few blog posts authored by our members (especially John Conde's "All about Silent Post" ) to help guide the way. I have a few more specialized questions however I was hoping some of you more seasoned folks could help out with.
The Authorize.net documentation includes this notification:
Test environment accounts do not process ARB subscription transactions. If you are using
a test environment account, you will not receive these email notifications in any form. You
will also not be able to receive an ARB subscription transaction Silent Post while using a
test environment account.
I was wondering if anyone knew if this means accounts set to TEST MODE in their control panels, or does this refer to the developer-only accounts available to those working on AuthNet platforms independent of deployments? The account we are using for testing is an actual merchant account set in test mode and we're receiving silent posts for virtual terminal payments done through the AuthNet CP, but even successful ARB's are not showing silent posts.
Also - what kind of parameters can be used to ensure that a silent post originated with AuthNet? I set up an endpoint and printed out the request objects from a silent post as well as the $_SERVER superglobal - it does not seem that they send any identification other than the MD5 hash set in the CP. This is fine, but I was wondering if there would be any advantage to limiting to specific remote addresses - I assume this is unlikely as the posts probably come from a datacenter with tons of IPs allocated for the task of sending silent posts.
Also, the ARB spec only sets a subscription status to SUSPENDED within AuthNet under very specific criteria (only if the failed payment is the first rebill and if not then after two attempts on subsequent days.) Is this a normal practice for suspending subscriptions? If we would like to make one decline trigger suspension, should the logic for revoking the feature also issue an UpdateSubscription API call and set to suspension manually in order to forgo the default spec?
I was wondering if anyone knew if this
means accounts set to TEST MODE in
their control panels, or does this
refer to the developer-only accounts
available to those working on AuthNet
platforms independent of deployments?
This refers to both. Any test ARB transactions will never be processed and not generate Silent Posts. It's probably why their developer forums are riddled with questions about testing ARB. Basically, the best you can do when testing it, besides setting up a live subscription, is to:
Test the API call by using a developer account. If you get a subscription ID back you know your integration is functioning properly.
Test Silent Post by sending a simulated POST submission to it. I can post a sample form for doing this.
Also - what kind of parameters can be
used to ensure that a silent post
originated with AuthNet?
The MD5 hash returned in the silent post is a hash of a string that includes an MD5 hash value (set in security settings) that presumably only Authorize and you know. Thus, you generate a hash on your end using the returned info plus the secret hash string and compare to validate the response. Specifics about the hash can be found here.
Is this a normal practice for
suspending subscriptions?
Normal practice? Honestly I don't know. I'm not sure how other companies handle it. There's a post somewhere in their community forums where an Authnet employee explains how it works but I was unable to find it to link to it here. It made sense to me when I read it.
If we would
like to make one decline trigger
suspension, should the logic for
revoking the feature also issue an
UpdateSubscription API call and set to
suspension manually in order to forgo
the default spec?
If a subscription fails it is automatically suspended by Authorize.Net so you don't have to do anything on your end. But you do need to update your user's account in your system and suspend it (assuming the subscription is for a user account of some kind).
I am selling stuff from here:
http://foundationletters.com/buy-master-mind-products/
One of the things on sale is a subscription to a specific website.
As you can see, I have connected e-junkie to my authorize.net account.
Let's say that I already have pre-generated accounts. In other words, I have logins and passwords that I am selling. I need to be able to convey them one at a time to every person that buys the product.
How do I do this?
I am sorry for such an open ended question. I prefer to not do much PHP / MySQL programming. Perhaps I can just have the person download a program that will automatically connect to a remote txt file from which it will grab an account?
But still i would need a placeholder, I would need to know which accounts are taken and which are not?
Please help if you have e-commerce experience selling "information" rather than physical merchandise using ecommerce with authorize.net
I think if I understand your question correctly, you want to be able to give people access to information/data (in this case, login credentials) upon completion of a transfer of funds (a sale), correct?
This is similar to a software license activation model wherein software vendor sells a license to use their software, the purchaser is given access to use the software by way of an activation key, product code etc. When done via. the Web, typically the seller, upon verifying payment from the buyer, makes the information available on the resulting Web page (usually called a receipt page). This is where the seller displays the sensitive data to the buyer. Customarily, on this page the seller will include a message such as "please print for your records". Additionally, it's very useful to allow the buyer to visit the Ecommerce site again at a later point to re-access the purchased information (if by chance they lost it).
Since you are selling "accounts", what your software could do (after payment is verified):
Generate a new username/password combination and store the credentials in whatever system depends on them to authenticate the customer later.
Display the credentials on the resulting Web page for the customer.
(optionally) Create an association in your database between the new "credentials" record and the new "order" record (not sure of your db schema, but using these names in place of actual entity names).
Hope this helps!
-aj
I currently have a php script that reads email messages sent from phones and then it posts them on the internet...
I want to do the same thing but instead of reading emails, I would like to process the data through a SMS.
so, if someone sends a sms to X number, my program would get the message through this X number and use it in the site.
What would I need?
You have a lot of options here. Generally speaking you need to first acquire the number that people can SMS to. Afterwards a callback will be issued to you when someone sends and SMS and your PHP script can process the message and figure out what to do with it.
You essentially have a few options for exposing the SMS
Go with a dedicated short-code. Eg someone sends a text to 53234 and you will get a callback to deal with it. This is an expensive option. It will cost you generally around $2500/mo minimum not including per messaging fees. You can requisition a short code through a provider such as Open Market. You have to get approval for the short code which might take as much as 6 weeks.
Go with a shared short code. This is a bit cheaper -- you pay per message and it usually costs anywhere from .02 - .10 /msg depending on your msg volume. You get a keyword such as DOLLY that people have to preface before texting. So they would text DOLLY INPUT TEXT HERE to 53234 now and you would receive the callback with INPUT TEXT HERE. Celltrust and others provide shared short codes.
Use a public api that allows people to text in through something such as TextMarks. Textmarks is like a shared short code requires keyword usage + users to subscribe. However it is free which is great and has a nice callback API. I believe a service called Mozes also provides similar service. Finally, if you want you can set up a Twitter account and have people text to their number. Facebook also a similar API that allows you to use their FBOOK shortcode.
Ish's answer was great. I'd like to point out an additional free option.
Most carriers allow you to send SMS messages to email addresses. The SMS text gets inserted into the body of the email and the subject is carrier dependent. Once the email is sitting in your inbox, you can access it by the method of your choice.
This method has worked for me in a personal project requiring remote communication with my computer when all I had was a cell phone without internet capabilities.
This Wikipedia page shows how many carries support this (practically all).
Just try not to violate anyone's terms of service, you could always host the email account yourself.