›

Small things about 3.0 API

ptomblinptomblin
edited 5:13PM in Developers
1. In the PHP-SDK, CheckfrontAPI.php defines function
// use to store API keys, ideally via an extended class. Not used for token pair auth
protected function store($data) {
}
But then calls it in the function tokens (line 370) with no arguments. The version of PHP that I'm using complains about that, so I changed that call to
$data = $this->store(null);
and the warning goes away.

2. Similarly, the function
// use to store session if needed for interactive integrations
public function session($session_id,$data) {
}
is called from the function api (like 246) without the second argument. Changing that to
$this->session($response['booking']['session']['id'], null);
makes the warning go away.

3. More importantly to me, the hack where I call "mobile/booking/{$booking_id}" to get the proper URL for the payment page has gone away!

Comments

  • JasonJason CEO Checkfront
    You don't need to call mobile/booking to get the proper payment url, it will be in the response to booking/create.

    Here's an example of what I think you are trying to do:


    <?php
    include('CheckfrontAPI.php');
    $Checkfront = new CheckfrontUI(
    array(
    'auth_type'=>'token',
    'host'=>'___.checkfront.com',
    'api_key'=>'XXX',
    'api_secret'=>'XXXXXX',
    'app_id'=>'My test',
    'account_id'=>'off',
    )
    );

    // get availability for date
    $query = $Checkfront->get('item/3/?start_date=20140806');

    if($query['item']['rate']['status'] == 'AVAILABLE') {

    $call = $Checkfront->post('booking/session',array('slip'=>$query['item']['rate']['slip']));

    // use this to add more items to booking
    $session_id = $call['booking']['session']['id'];

    $post = $Checkfront->post('booking/create',array('session_id'=>$session_id,'form'=>array('customer_email'=>'test@checkfront.com'
    ,'customer_name'=>'Jason')));

    $return_url = $post['request']['data']['url'];

    print $return_url;
    }
    ?>
  • ptomblinptomblin
    Yes, the mobile/booking hack was because under the old API, the url I got wasn't the customer one, it was the employee one. That's what Kris told me to do. However, now that I'm passing in the account_id => off argument to the constructor to the CheckfrontAPI class, I don't need it any more - the url is the correct one.
  • KrisKris
    We do like to get feedback on using the systems, and what you'd like to see. There's only so much we can do with a small team, and input from our community is an important part of the process.
    I've put in a quick commit to the SDK library example functions re your notes, but if you have a Github account you can feel free to submit any pull requests or other issues if you find anything else you think would benefit the SDK.

    On the customer URL issue, we've also made the customer token available on other calls to the booking, so it is much easier to debug or manually reproduce an invoice request.
This discussion has been closed.