-
Notifications
You must be signed in to change notification settings - Fork 37
HIPS Overview
- https://hips.com/se/docs
- https://static.hips.com/doc/api/index.html?shell#introduction
- Usage pricing: https://hips.com/se/pricing
The term "Client" refers to SHF. The term "Customer" refers to anyone interacting with the SHF website to pay SHF - typically, this means a member, who is paying a membership fee and/or "branding" fee. (in the future, a customer might be a SHF-associated company, which might be paying fees on behalf of itself and/or its associated members or employees).
- John - CEO, Founder
- Martin - Development Manager
- Employees - 2 Full-Time Developers, 3 Outsourced Developers, 2 Finance (CFO & Controller), Sales & Support currently 1 but going to 3 in September
John had previously started and sold another payments-processing company. He started HIPS after expiration of a non-compete clause associated with that sale.
The company which bought John's prior company is an investor in HIPS. John states that they are well capitalized and can self-fund "as long as we need to".
HIPS service has been in use, in pilot phase, since May. All customers are currently in pilot phase. One or more customers transition to "production" phase in September.
HIPS strategy is to provide equal or better processing capabilities at a lower cost. They may raise prices when they've achieved adequate market share (John references "a couple of years" for that to occur).
-
Debit and Credit Cards
- All cards used in Sweden (Visa, MC, Amex, etc.)
- Do not need a Merchant account
-
Invoice (pay later)
- Customer supplies information necessary to identify themselves
- HIPS performs credit check in real-time
- Transaction goes through, revenue is credited to client (SHF gets funds directly from HIPS)
- HIPS gets paid by customer (invoice is dent to customer, who has 14 days to pay)
NOTE: Membership Fees are deemed to be “high risk transactions” (because they can have high levels of ‘chargebacks’). Thus, payment to the client occurs 14 days after the end of the current payment cycle (payment cycle ends on Monday)
- Swish - the client has to enable Swish payments for their account
- "Swish Hamdel" (online) to be enabled
- SHF does not need a merchant account to use Swish (that is covered by HIPS<>Swish contract)
NOTE: SHF does not have a Swish account at this time. Susanna says they’re working on getting one.
- Paypal - the client has to enable PayPal payments for their account
- Do not need a Merchant account
- Credit and Debit Cards
- Payment Authorization: all currencies supported
- Payment Settlement: Krona, Euro, USD (Norway, Denmark, UK coming soon)
- Invoice: Krona only
- No fixed, recurring or initiation fees
- Credit cards, debit cards, invoice payments: 1.8% plus 1.8 krona / transaction
- Swish: Has own cost structure
- Paypal: has own cost structure
- Refund processing incurs no additional fees beyond the initial transaction. (They have an API that can be used for automating this, and they also enable the client to do this themselves via the HIPS account dashboard).
NOTE: My notes say that PayPal and Swish have fees "on top of" the card fees noted above. Ashley's notes say that these services are "free" from HIPS point of view - need to resolve.
HIPS is level 1 PCI compliant. Among other things, this means that they are certified as compliant with many security requirements, they are audited every year, tested every 3 months by with white-hat hacking, etc.
They maintain all customer data for at least 10 years.
We (SHF team) decided that we don't need details about all of this, given that the PCI criteria would certainly encompass all of our concerns. We did ask to see their attestation of compliance from the PCI organization.
- Support is provided through multiple channels, including Email, Facebook, Support Portal (support.hips.com) & Phone. (John will also create a Slack channel for support (hips-support)
- Support is generally provided during SV business hours. However, best efforts will apply off-hours.
- There is no charge for support.
- Response time for acknowledging a support request: Within 24 hours
- Response time for resolving a support request: Depends on type of request
- Both the organization (SHF) and the development team are ‘customers’ and can contact support
- "API Only" - Here, we interact with HIPS only via their transaction API (that is, we do not integrate their native payment processing capabilities in our payment workflow).
- We send the order, and the customer's card number, to HIPS
- HIPS processes the order, returns "OK" and a transaction ID
- We can use the transaction ID to query or request additional processing by HIPS later
- NOTE: Since this option requires SHF to process a customer credit card, SHF would have to be PCI compliant to use this option.
- "Payment API" - In this case, we integrate our order form with HIPS via:
- Customer enters card number in our form
- Data submit triggers an API call to HIPS with order and card details
- HIPS processes the order and returns a token number
- We can use the transaction ID to query or request additional processing by HIPS later
- We (SHF website) does not "see" the credit card, so PCI compliance is not required.
- "Checkout API" (aka "full integration", "HIPS.js") - here, we embed an order form - generated by HIPS - in our page using an iframe. HIPS handles all order and payment processing from there.
- Does not require PCI compliance.
- HIPS has more control over the transaction, and thus can do a better job at fraud detection.
Please provide an overview of payment processing. | Option 1: API has to be PCI certified, fewer than 1mil transactions. Options 2: Hips JS connects to a form, sends the card No. directly to Hips server, replaces card No. with a token not seen on the front of the site. Option 3: Hips JS Recommended creating a checkout easy to integrate, if you add payment methods later it will automatically be there, this does not need PCI compliance, The website refers to "PCI-free" and "PCI-required". Please explain. | PCI-required means transmit or store the Card Number, need to be certified.
3 options for working with HIPS:
- API must be PCI certified (“easy” for a non-profit organization) send a card number, HIPS send OK/NOT OK back
- PCI required if we transmit or store. In this case we’re transmitting it, so PCI certification needed
- HIPS JS with the form - HIPS handles the card number. No PCI cert. needed
- connect it to a form. when a customer enters a creditcard number, SHF-projects the card number to the HIPS server, HIPS returns a token. SHF never saves the card number! (SHF saves the token saved by HIPS. and will send the token to HIPS when needed
- works like an iframe
- HIPS JS at the checkout [recommended]
- totally hosted on HIPS server
- works like an iframe (martin example with Zerpico glasses) ex: at checkout, is redirected to hips server
Q: can we decorate it?
- fonts and colors
- within an Iframe
- so as long as we handle CSS?
(not really clear from them. they kept repeating the iframe thing.
I wonder if they have )
- End user logs in to HIPS. (ex: like logging in to Paypal. end user needs to get a 2-factor etc.)
- verified by the person-number and their postal code
- if they chose not to enter it, then the invoice option is not available
- Invoice: will need to enter their BankID (like a 2 factor authorization)
Suss Q: works for an organization?
Q: SHF does bank transfer. can this be done?: handled via “invoice"
- (is more like ACH transfers; or a little bit like setting up approval for your utility company to take funds (or even put funds) directly into an account
Q: recurring payments?
- do an API request to HIPS
first transaction: use unqiue ID for the customer, send info to HIPS so that we can query HIPS later about the status.
- cannot do with PayPal and Swish (because PayPal and Swish require extra steps from the end user)
PayPal: SHF -> HIPS -> PayPal -> SHF (url sent)
Q: why are the 2 JS methods recommended over API? “least work for SHF, more control for HIPS” HIPS can do more verfication of the user. HIPS has more control of info (ex: fraud protection )
- HIPS has more control over the customer experience (they have more/better experience with it)
SHF project system would work with their interaction API (this is not the same as the API level above)
- so SHF would essentially do an invoice (payment refund) back to a member
demo: log into HIPS can see all transactions - can click on a customer and view a specific order and view the payment(s) made
-
can click on “refund payment” (in full or in part, etc.)
-
can add a note, print out things, etc.
Development Support
Q: is there a sandbox for development?
yes - can set the account (domain) to LIVE or Test mode
when domain is registered in HIPS will get API keys
development docs?
- susanna has the API docs (link)
ex: there is 1 API call that requires PCI certification (because it sends the CCard number (Payment API: POST)
HIPS JS
= the “tokenization feature” of HIPS (so that we can use the token instead of the ccard number)
checkout payment API can use either the token or the actual ccard (this requies
Checkout: Order API
- create an Order. -> HIPS -> we get a token back (like an ‘order number’)
Topic | Discussion Notes |
---|---|
How do we get access to development docs? | |
^^ Available in English? | |
What language(s) does your API support? | |
What are your support SLA terms? | |
What kind of development support do you provide? (free? cost?) |
they work in Ruby, but most clients using PHP.
- working with WooCommerce, Magneto, etc.
Q: Patrick: how does it work if we’re stuck?
-
normal support ways (phone, website: (support.hips.com. have a support ticket tracking etc.)). could do a slack channel, etc.
-
can use the #hips-support Slack channel
John & Martin: will send us a doc showing how a transaction would work in Ruby
= HIPS each trx is tied to whomever is PAYING (so if an organization owner pays, HIPS tracks that, and SHF would need to organize, present the info as we want)