Difference in Hypermedia API and FoxyCart API

richtestanirichtestani Member
in General edited July 2015
I noticed the docs referring to the Hypermedia API, as well as your own.
What is the difference between the two?
Which are you officially supporting?
What are the requirements for the Hypermedia?
Any advantages to using one over the other?

Sorry for the rapid questioning, I am just curious about the differences.
I've built some tools on your own and didn't know if it was the better
choice.

Thanks
Rich
Tagged:
Comments
  • fc_jedfc_jed FoxyCart Team
    @richestani

    Thanks for all your questions. I'm glad you're taking an interest in that. The API is one that has been implemented for several years now, which gives users more custom control of some FoxyCart functions, like working with datafeeds and webhooks. This is especially useful if you want to automate tasks that concern your webstore.

    On the other hand, the Hypermedia API is designed to give users complete control over your FoxyCart store. Anything you can do in the FoxyCart admin, you can also do through this API which means you can embed Foxy into any application. This is fairly newer and we've recently been making a serious push to get users on board with this as we improve our service.

    We officially support both API and hAPI, as they have their different functions. Put simply, hAPI could very well be seen as the next step of the API. There are no additional installation requirements for the hAPI. Have a look at this link for more information on how to use it: https://github.com/FoxyCart/foxyclient-php

    You can also check out the Getting Started section in hAPI to get a clearer view of its function. Also, I advise you to check out the playground to see how hAPI is implemented.

    If you have any further questions, please don't hesitate to ask.
  • Awesome, thank you for that answer.
    To use hAPI, does it matter which version of FoxyCart is in use?
  • fc_jedfc_jed FoxyCart Team
    @richestani

    I'm not quite sure if there's a restriction, but it's generally recommended to use the latest version (2.0) as the hAPI is based on the latest admin.
  • Hi, can you explain more about this to a non-developer with a specific use case?

    There's a website that gives an instant quote. If quote is accepted, there's a 3 step form to gather more information about the purchase, ending with a payment form collecting the quoted fee.

    The payment collected is a % of the total fee.

    After further consideration by the merchant, the fee might be refunded and quote cancelled.

    If accepted by the merchant, there might be an adjustment in originally quoted amount (increased) before the balance owed is charged in a 2nd payment.

    There's a 2nd payment charged for the remaining % of the quote.

    ----
    All of this doesn't fit the FoxyCart cart checkout concepts, but does involve payments. We want to use FoxyCart to manage our interactions with Stripe for such payment processing. Does your hAPI suit this kind of use case?
  • fc_jedfc_jed FoxyCart Team
    @patrickpitman

    I'm not quite sure how the API or hAPI would apply to the use case you mentioned. Put simply, the FoxyCart API performs the additional functionality detailed here, while the hAPI allows you control of all the functionality your store admin is capable of programatically.

    What you need for your case is the use of Purchase Orders to process the quote without any payment involved for the first. After the fee is approved, you can then process it as a 2-part recurring payment.
  • Thanks. So it seems that https://wiki.foxycart.com/v/2.0/api is what I'm wanting to deal with for processing payments. If yes, is there any way to avoid the outcome that web visitors need get redirected to our foxycart store domain name for final checkout form?

    Also, visitors make payment when accepting a quote, as a % of the total. So there is no purchase order need, if that would assume delayed payment. It's not delayed, it's partial. So we want first-time visitor to complete step1, step2, step3 of form and conclude with a payment. Then a balance is owed, to be charged to same card upon delivery some days or weeks later. (That delay is also problematic, isn't it?)
  • fc_adamfc_adam FoxyCart Team
    edited September 2015
    @patrickpitman,

    For what you're describing the API isn't what you need. For charging customers an additional amount later - you could make use of Unified Order Entry (UOE) to allow you to process transactions on their behalf. You'd also want to force customers to create an account during the checkout, removing the ability to have guest checkouts.

    More information on UOE here: http://www.foxycart.com/features/feature/payment-methods/unified-order-entry
  • Hi Adam, I'd like to follow-up on your comment.

    The UOE would require we have the card present to reenter on the customer's behalf, right? But we don't have that card number, not available to us.

    We've set up a FoxyCart store and are running payment #1 through Foxycart linked to Authorize.net.

    Could we create a Customer Informatoin Manager (CIM) profile at Authorize.net that could somehow be accessible via FoxyCart?

    Seems that when FoxyCart sends along to Authorize.net, there's no customer profile created at Authorize.net that we could alter hook into and use (even from our own custom web app). Does that sound accurate?

    Objective: Some weeks after the initial payment number 1 for 10% of the purchase price, we want to arbitrarily, manually, trigger the 2nd payment for 90% of the purchase.

    Seems it's not a UOE, nor Purchase Order, nor Subscription. Other ideas?
  • fc_adamfc_adam FoxyCart Team
    @patrickpitman,

    UOE relies on the customer having created an account - and allows you to login as that customer using your master password and their email. When you login as a customer, all of their information is loaded in - including their saved password (but masked for security). That means that if the customer has created an account before, you can use UOE to complete a checkout as them.

    You're right that we don't create customer profiles on Authorize.Net. We manage the customer payment information securely on our side.

    As long as you're requiring the customer to create an account, UOE will be your answer.
  • Adam, so when an account is created, then FoxyCart saves card data? And via UOE, then we could modify next payment?

    Possible to obfuscate account creation so customer doesn't need to choose password, and do it behind the scenes?

    Our business is mostly a one-time purchase, it's rare, so customer wouldn't want / need that password.
  • fc_adamfc_adam FoxyCart Team
    @patrickpitman,

    In version 2.0 - if the customer creates an account, then we securely save their payment details automatically. Earlier versions also had a checkbox allowing customers to optionally opt out of saving credit card details when creating an account.

    You could hide the password field and automatically fill it with a random password - but if that customer did happen to come back to purchase again, they would have no idea what their password would be that the checkout would prompt them for.
Sign In or Register to comment.