Page 1 of 2 12 LastLast
Results 1 to 25 of 30
  1. #1
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59

    API orders and SKIPPED charges

    We've setup a Point-Of-Sale (POS <- yes we laugh at that too) system to create orders and defer charging the credit cards. The API is creating the invoice, adding the order items, applying the affiliate and commission and creating the pay plan properly.

    Everything runs fine during the day. All of the data is double checked and is showing correct in the database. The credit cards are then processed by the backend we setup and charges are accepted or declined, and declined customers are then called to the back of the room to deal with the declined charges.

    The deferred CC payments keep the lines moving quickly, and problem can be dealt w/ in an easy & timely fashion as well.

    "What's the problem?", you ask.

    The problem is this everything runs fine during the `day`, in the evening when the deferred CC payments are processed, the API returns the 'SKIPPED (there was no balance to charge)' message.

    http://help.infusionsoft.com/develop.../chargeInvoice

    The next morning everything returns to normal and processing is now working again.

    Epiphany! "What's the date on the order?!", you ask. Yes, we had the same realization, and compensated for that. Due to the differing timezones these events take place in, the POS time is set for UTC. When we send an order through the API we set the date to EST to Match the Infusion server.

    We thought maybe there was a problem with DST over the weekend because we still got these errors, but when you do the time conversion for the orders that were taken at 18:00 EST, you get 21:00 UTC, even with the 1 hour for DST, you're still on the same day.

    Now, here's another monkey wrench to through in to the problem. When the invoice is processed through the Infusion UI, the charge is run correctly with no alterations to the pay plan attached to the order.

    So having said all of that...

    Why does the API tell us there is nothing to charge?
    Why does it work fine when processed through the Infusion UI?

  2. #2
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Marion,

    This happens because you are not creating the orders with the correct time zone.

    That's why in the evenings, at some point, your date and time goes into the next day adn when Infusionsoft tries to process the payment, it finds that the payment is not yet due.

    Ensure that all your orders are set to EST and the problem will disappear.
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  3. #3
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    Bob, thanks for the reply, but I'm not sure you read all of my post. We assumed this was the case, but I am converting the time to EST, and I verified that timezone with Infusion.

    Each time we create the order and pay plan in Infusion, I'm changing the date to EST from UTC, and the orders do show in the Infusion UI with the correct date along w/ the correct payment dates.

    So setting the TZ and modifying the dates to EST has not solved our problem. What is it that I'm not seeing?

    Let me ask this question. Say that the order is place on the 4th @ 6pm EST and then we try the deferred charge at 12am on the 5th EST. Would that still pass the SKIPPED message because it's looking for a charge on the current day, and there isn't one?

    I guess in my mind I would assume that it should look for any payment that's been missed through the current date and process it/them to bring the pay plan current.

  4. #4
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Marion,

    I'm only aware of this issue occurring when there's a mismatch in the time zones.

    Each item during the process needs to be converted to EST or the order will be skipped.

    The time on the POS is one thing. The relevant time, however, is that of your server and what it communicates to Infusionsoft.

    All I can tell you is to really ensure that your time zone is correctly set and that the date/time in your data is correct.

    The date it finds and the records that will be processed MUST be in the past. Future date/times will result in a SKIPPED order.

    If that doesn't fix it, you may have a different issue although it seems to be TZ related.
    Last edited by BobKeen; 11-07-2011 at 07:44 AM.
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  5. #5
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    Ok.. so I just took a long look at a couple of the invoices that were skipped. What I see is that `Yes` the order and payment dates are the same, but the payment that was skipped and processed through the UI has a date for the following day.

    So it looks like the chargeInvoice() method is only looking to charge orders for the same date as the request, and doesn't look for missed payments to bring the account current.

    Can someone at Infusion verify this and offer a possible work around?

  6. #6
    Marion,
    For clarity, what you are saying is that if the invoice/order has a payment that was due in the past, but not on the "current" date, it is being skipped?

    If you can confirm I have understood this correctly I will run some tests and see if there's a problem within the chargeInvoice method.
    JUSTIN GOURLEY
    Test Automation Engineer


    "The fish who keeps on swimming, is the first to chill upstream" - 311

  7. #7
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    Yes, that's what I'm saying. The order and payment date in the order were both set for the 4th. It looks like the chargeInvoice() was attempted to be run on the 5th and we received the SKIPPED message.

    Based on what Bob said this is the only date that's not the same as the order and payment plan.

    The app is: mmi
    Job ID: 55506

    With that I think you should be able to see the data.... and thank you for letting me know I'm `possibly` not hallucinating this problem

  8. #8
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Marion,

    I believe it's not just a date but a date/time field. Even if that date/time is only one minute AFTER the attempt to charge is run, it will be considered a "future" date.
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  9. #9
    After thinking about the way our system functions I believe that your problem is occurring because although you are setting the order/invoice to an earlier date there is not yet an existing payment plan in the database telling the system when the amount is actually due.

    So, after you create the blank order, try calling the InvoiceService.addPaymentPlan method and set its due dates accordingly.
    JUSTIN GOURLEY
    Test Automation Engineer


    "The fish who keeps on swimming, is the first to chill upstream" - 311

  10. #10
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    We are adding the payment plan. We realized early on if we didn't have that, nothing processes at all. Here are the iSDK calls in order of use.

    blankOrder()
    addOrderItem() // Product price
    addOrderItem() // Finance fee
    addOrderItem() // Tax

    manualPmt() // Trans
    manualPmt() // Cash
    manualPmt() // Coupons
    manualPmt() // Checks

    // Credit cards are validated, but not processed

    payPlan()

    When we look in Infusion it all checks out.

    The order date, the product, the line items, the manual payments (if any), the remaining balance and the pay plan.

    Allow me to also provide these details while trying to find the problem on our end.

    1) My boss told me he changed the order and pay plan date to the 5th, so the order and pay plan were initially added via the API on the 5th. He changed the date to the 4th trying to get it to process using our backend POS.

    2) I quickly read the infuDate() method and followed the example to get the date in Infusion. What I found was that the time that got passed through was 00:00:00 on all of the orders for Nov 4th. Example: 20111105T00:00:00

    I'm still not sure if those two things change the issue. I've adjusted the dates for the orders, manual payments and the pay plan to pass through the correct hour, mins and seconds (based on what our server says is EST).

    The part that has me perplexed is that when run through the Infusion UI, it processes the 1st payment just fine. No message of Skipped or any sign of a problem.

  11. #11
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Marion,

    This is what I ended up using to properly code an EST date/time for my API orders:

    Code:
    $date = new DateTime();
    $date->setTimezone(new DateTimeZone('EST'));
    $OrderDateTime = $date->format('Ymd\TH:i:s');
    I charge immediately, using the chargeInvoice() method, so I can't tell you much about the finesses of using payment plans, for which I've never had any use.

    As you'll note in the code above, I do not use the infuDate() method to compute/generate an order date. I don't know which parameters you're passing to infuDate(), but in this timezone business, I found it safer to do it as above.

    I ended up doing it this way because it drove me absolutely nuts. What worked during the day, stopped working at night and I would get the message 'SKIPPED (there was no balance to charge)'.

    By now my former problems should sound eerily familiar.

    My entire script was fine and required no other changes EXCEPT to correctly assign a timezone-adjusted date/time during "blankOrder()".

    Once I did that, my orders would process correctly day and night.
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  12. #12
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    Bob, thanks for the code, and your help in this matter.

    I tried to determine the difference between your code and the infuDate() method. Essentially the code I have is doing what yours does. It changes the PHP date to use EST and create the date to send to Infusion. Here's what I'm getting right now.

    string(24) "Nov 8, 2011 00:26:35 UTC" // Current server time
    string(24) "Nov 7, 2011 19:26:35 EST" // EST time
    string(17) "20111107T19:26:35" // InfuDate()
    string(24) "Nov 8, 2011 00:26:35 UTC" // Return to UTC
    string(17) "20111107T19:26:35" // Using BobKeen code

    As I stated in my previous post the H:i:s was getting passed as 00:00:00, but still would've been the same date, and as you can see the infuDate() method is giving the same result as your code.... I just don't get it.

  13. #13
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Marion,

    00:00:00 could be the problem. It isn't only the date that is relevant, but the date/time.

    I'm not saying you're doing anything wrong. I'm just saying that at one point, I hit the same wall and that's how I fixed it, after spending two days and nights on the issue (I think you're coming close).

    Why this worked for me and no other timezone conversion, I don't know. Why every other logical approach failed, I also don't know. This was the working solution and I'm not touching it.

    Again,though, I do NOT use any payment plan...
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  14. #14
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    Bob, thanks for the help.

    We have two more events this weekends that the POS will be used for. I think the problem is a compounded one. The lack of the accurate time, and the infuDate() method using the native PHP parse_date() function which doesn't like like zeros in front of the month and I would also assume the date.

    Well see what happen Saturday night. I'll post the results when we know what's going on.

  15. #15
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59

    [Resolved] Update based on events this weekend

    The problem has been resolved.

    When using the infuDate() method, you need to pass through the the time as well.

    http://help.infusionsoft.com/develop...thods/infudate

    Originally [when I setup my code], I was reading the documentation and followed the example. I never looked at the actual method to see what it was doing.

    I made the assumption that if I passed the:

    $currentDate = date("d-m-Y");
    $oDate = $app->infuDate($currentDate);

    ... that the method would resolve the proper timestamp, but it doesn't.

    So the final code was:

    Code:
    $current_date = date("j-m-Y H:i:s");
    $sale_date = $objIS->infuDate($current_date);
    ... and payments processed correctly when requested (and the CC wasn't declined ).

  16. #16
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Marion,

    You can do what I did, which was to add the correct timezone-relevant date/time to infudate() when none is passed - this way I never had to worry about it and it's always the right time (in the right place).
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  17. #17

    Join Date
    Sep 2011
    Location
    Goodyear, AZ
    Posts
    30

    Word Press Group Site

    Hi Bob,

    We recently started a group buying site. I want to simply create an API which takes the users (as they registar on the site) and push them into Infusionsoft for follow up campaigns. I have gotten the encrypted API key.

    The only info I need to get from the WP site is First name, Last name and Email.

    Is there a base set of code and where is the placed on the WP site? Trying to get an understand in some basic API.

    Thanks,
    Douglas J. Masi
    VICO Systems LLC

    Senior Partner
    Judge Us By Our Actions, Measure Us By Your Results
    Facebook - VICO iSchool
    Facebook - VICO Systems
    Facebook - DJMasi

    480.331.5741
    info@VICOSystems.net

  18. #18
    Infusionsoft Certified Consultant BobKeen's Avatar
    Join Date
    Jul 2011
    Location
    Bradenton, Florida
    Posts
    743
    Doug,

    It's certainly feasible but it has its complex side.

    First, out of the box, WordPress' registration only allows for a username and an email address. The username may be a nick ("Darth Vader") or part of someone's real name, but you won't be able to tell which is the case.

    During the registration process, WordPress offers a "hook" through which you'd be able to send the information to Infusionsoft. The action hook is called "register_post". You can write a short script that would use the API to add the new contact to Infusionsoft. The last time I checked, the API will let you add contacts without first or last names.

    Alternatively, there are a number of WordPress plugins "out there" that will let you modify the default WP registration form (Subscribe2, for example). You could install such a plugin and define input fields for first and last name.

    Since the action hook is run after a POST, all the fields should be available to you through PHP's $_POST variable.

    That would be doing it the way you were thinking of doing it.

    Personally, I would do it backwards.

    Instead, I would disable the "Anyone can register" option in WordPress and I would give them an Infusionsoft web form to fill out with the (required) fields I wanted. In this case, first and last names as well as email address.

    Once they complete the form, you can redirect them to "thank you" page where this data will be passed to the target page.

    From there, it would be very easy to add the new contact to the local WordPress database by using two functions in your script, wp_create_password() followed by wp_create_user(). You can see an example of how it's done in the wp-login.php file.

    You could also take a look at infusionWP, which has all this built-in for you - and tons more....
    Best,
    Bob

    Check out iMember360 (or here), the leading integration system for Infusionsoft-based membership sites, automated landing pages, secure digital delivery and more. Using the world's best CMS, build dynamic, individually customized and interactive membership sites, using any of thousands of free themes and plugins, connect with Facebook, Twitter, etc.


  19. #19

    Join Date
    Sep 2011
    Location
    Goodyear, AZ
    Posts
    30
    Thanks Bob will looking into those options. Is Infusionwp a plugin? Will check it out.

    Doug
    Douglas J. Masi
    VICO Systems LLC

    Senior Partner
    Judge Us By Our Actions, Measure Us By Your Results
    Facebook - VICO iSchool
    Facebook - VICO Systems
    Facebook - DJMasi

    480.331.5741
    info@VICOSystems.net

  20. #20
    I just had this problem with the date issue last night. My issue was actually with Wordpress changing the date. My server is set to EST because I'm in EST. My Infusionsoft is set to EST as well. My Wordpress is set to EST. All are on the same page. For some reason, however, when calling wp-load.php on a page outside of the Wordpress template, wordpress reverts the time back to UTC. So I could literally echo date('Ymd\TH:m:s') before I included wp-load.php and again after I included it and get 2 different times.

    There was probably a better way to resolve the issue since this way will be overwritten if I update WP, but I replaced this line of code in wp-settings.php:

    date_default_timezone_set( 'UTC' );

    with this line of code:

    date_default_timezone_set( 'America/New_York' );

    I don't worry about the time...I actually set it order date to date('Ymd\T00:00:00'). This is effectively what infuDate does, but without the call to the API. A misconception about infuDate is that it returns Infusionsoft server time, but it doesn't. It just returns a formated version of what you put into it. So if you're putting the wrong server time in, you'll get the wrong server time out. I find that as long as it's in the past, when I run chargeInvoice, it works.

  21. #21
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    Quote Originally Posted by nick View Post
    ...I don't worry about the time...I actually set it order date to date('Ymd\T00:00:00'). This is effectively what infuDate does, but without the call to the API. A misconception about infuDate is that it returns Infusionsoft server time, but it doesn't. It just returns a formated version of what you put into it. So if you're putting the wrong server time in, you'll get the wrong server time out. I find that as long as it's in the past, when I run chargeInvoice, it works.
    Yes, this was our problem, and since we weren't charging the invoice immediately, that's what was causing our `skipped` issue. When I looked at what the code was doing I passed through the time, and that resolved our issue.

  22. #22
    I am still having this problem. I've tried every variation of the date on here, and still get "SKIPPED" for every payment plan attempt.

    I'm doing the following (although I've tried every variation in this thread):
    $current_date = date("j-m-Y H:i:s");
    $oDate = $app->infuDate($current_date);

    $newOrder = $app->blankOrder($newcontactId,"Purchase", $oDate,0,2);

    $stDate = $app->infuDate($oDate, strtotime("+30 days")); //second date as 30 days out

    $result = $app->payPlan($newOrder,true,$newCard,2,2,3,197.00,$oDa te,$stDate,6,30);
    Last edited by Jon Fairchild; 05-01-2013 at 04:14 PM.

  23. #23
    marion's Avatar
    Join Date
    Nov 2011
    Location
    VA
    Posts
    59
    @Jon,

    It's been awhile since we dealt with this, but it all came down to the time. Just out of curiosity, did you confirm that all of your arugments are cast to the correct data types for the Infusion method?

    http://help.infusionsoft.com/api-docs/invoiceservice <-- look at the Type column.

    Make sure your dates aren't being passed as strings.

  24. #24
    Quote Originally Posted by marion View Post
    @Jon,

    It's been awhile since we dealt with this, but it all came down to the time. Just out of curiosity, did you confirm that all of your arugments are cast to the correct data types for the Infusion method?

    http://help.infusionsoft.com/api-docs/invoiceservice <-- look at the Type column.

    Make sure your dates aren't being passed as strings.
    I even tried explicitly setting it up like this:
    $date = new DateTime();
    $date->setTimezone(new DateTimeZone('EST'));
    $currentDate = $date->format('Ymd\TH:i:s');
    $oDate = $app->infuDate($currentDate);

    But wouldn't passing any date to infuDate-> spit out a datetime on the other end?

    I also tried adding or subtracting 5 seconds and 5 minutes, no luck either way.

  25. #25
    I'm doing a 3 payment plan, is it an option to do a chargeInvoice for the first payment, and then do the payPlan for the other two charges to get around this? I'm worried the other two won't charge down the road.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •