How to do payments without saving payment method

273 views
Skip to first unread message

Anurag Phadnis

unread,
Apr 12, 2021, 1:00:08 AM4/12/21
to Kill Bill users mailing-list

I want to use killbill only for processing payment and I do not want to save anyone's card information. I want user to be redirected to the payment page (stripe/adeyn) when they want to do the payment and be able to choose any payment method at the time of checkout. How to do this using killbill?

Pierre-Alexandre Meyer

unread,
Apr 12, 2021, 10:05:02 AM4/12/21
to Anurag Phadnis, Kill Bill users mailing-list
Hello,

This is described in details in our payment manual: https://docs.killbill.io/latest/userguide_payment.html#_payment_methods


Hope this helps,


On Mon, Apr 12, 2021 at 6:00 AM Anurag Phadnis <phadnis...@gmail.com> wrote:

I want to use killbill only for processing payment and I do not want to save anyone's card information. I want user to be redirected to the payment page (stripe/adeyn) when they want to do the payment and be able to choose any payment method at the time of checkout. How to do this using killbill?

--
You received this message because you are subscribed to the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/10745b3f-453e-4c28-a59d-2fef50fd9e9an%40googlegroups.com.


--
Pierre

Anurag Phadnis

unread,
Apr 12, 2021, 10:20:49 AM4/12/21
to Kill Bill users mailing-list
According to the flows mentioned in this document we first need to create a payment method for an account. This essentially means that we are saving the card (either on payment plugin or on our end) and allowing future transactions to happen without need to enter card details. But as of now is there any flow in which we do not need to create a payment method and save it.

The flow that I intend to implement is the following

1. User clicks on the checkout button in UI
2. Checkout request is received on the applications server
3. Application server invokes killbill to create a transaction
4. User is redirected to the hosted page created by payment plugin
5. User performs a transaction on that page(using any card, or payment options provided by stripe)
6. Killbill updates the payment status on the transactions

Is this flow possible by using killbill, if yes which API should be used?

Pierre-Alexandre Meyer

unread,
Apr 12, 2021, 10:46:03 AM4/12/21
to Anurag Phadnis, Kill Bill users mailing-list
Kill Bill needs a payment method to be able to trigger a payment, but that payment method doesn't need to have a re-usable credit card token attached to it.

The flow you are describing is what Kill Bill calls a Hosted Payment Page flow: https://docs.killbill.io/latest/userguide_payment.html#_hosted_payment_page_flow

A payment method still needs to exist first on the account, as it is how Kill Bill knows which plugin to invoke. But as mentioned, this can be a "shell" payment method, i.e. a payment method with no card associated with it in the plugin.

Kind regards,

a...@caravelo.com

unread,
Apr 13, 2021, 8:40:58 AM4/13/21
to Kill Bill users mailing-list
Hello,

Sorry to step in, but I find this use case interesting, at least on one of its possible declinations.

Suppose that one wants to use Kill Bill as a "generic" payment gateway , i.e. as an abstraction layer for different PSPs, so to offer the same interface to client applications despite the actual PSP used for payments. This means also the ability to do "anonymous" payments by the mean of HPP, i.e. for any casual final user, without the need of creating a user account. In short, a client application would require a payment form for a given PSP to Kill Bill, so to allow the unregistered final user to pay. My idea to realize this use case was creating a "service account" in Kill Bill, having all available "shell" payment methods. Then all payments would be made by using this same user, without the need of creating a new account for each final user.

Is this approach valid? There is some limit in the number of payments that a single Kill Bill account could reliably hold?

Best regard, and thank you!
--
Alessio Gaeta

Pierre-Alexandre Meyer

unread,
Apr 13, 2021, 9:59:16 AM4/13/21
to a...@caravelo.com, Kill Bill users mailing-list
On Tue, Apr 13, 2021 at 1:41 PM a...@caravelo.com <a...@caravelo.com> wrote:
Suppose that one wants to use Kill Bill as a "generic" payment gateway , i.e. as an abstraction layer for different PSPs, so to offer the same interface to client applications despite the actual PSP used for payments.

FWIW, this is a very common use-case for Kill Bill. It's basically how the payment system at Groupon works (check out our tech talk: https://www.youtube.com/watch?v=-wUkxECbUu4).
 
This means also the ability to do "anonymous" payments by the mean of HPP, i.e. for any casual final user, without the need of creating a user account. In short, a client application would require a payment form for a given PSP to Kill Bill, so to allow the unregistered final user to pay. My idea to realize this use case was creating a "service account" in Kill Bill, having all available "shell" payment methods. Then all payments would be made by using this same user, without the need of creating a new account for each final user.

I would not go down that road (1:N payment methods where N is very large isn't a great position to be in).

Even if the end user doesn't have a proper "account" for the client application, there is still some form of id that uniquely identifies that customer (since he's paying for *something*). I would create an account tied to that id in that case.

One practical example is when Kill Bill is used as the payment platform for a provider of inflight wifi service (on-demand use-case, not subscription-based). The end customer may not have an account at the provider, but there is something that uniquely identifies him for the duration of the flight (email address, seat number, etc.), as this is needed to switch devices, reconnect, etc. In this case, you would create "on-demand" accounts associated with that id. A frequent flyer might end up with as many as one "on-demand" account by flight taken behind the scenes, but this scales *very* well and is quite easy to manage.

--
Pierre

Alessio Gaeta

unread,
Apr 14, 2021, 3:21:40 AM4/14/21
to Pierre-Alexandre Meyer, Kill Bill users mailing-list
Il giorno mar, 13/04/2021 alle 14.59 +0100, Pierre-Alexandre Meyer ha scritto:
On Tue, Apr 13, 2021 at 1:41 PM a...@caravelo.com <a...@caravelo.com> wrote:
Suppose that one wants to use Kill Bill as a "generic" payment gateway , i.e. as an abstraction layer for different PSPs, so to offer the same interface to client applications despite the actual PSP used for payments.


FWIW, this is a very common use-case for Kill Bill. It's basically how the payment system at Groupon works (check out our tech talk: https://www.youtube.com/watch?v=-wUkxECbUu4).

Yes, of course, I just did not not had clear how to behave in case of casual payments :)

This means also the ability to do "anonymous" payments by the mean of HPP, i.e. for any casual final user, without the need of creating a user account. In short, a client application would require a payment form for a given PSP to Kill Bill, so to allow the unregistered final user to pay. My idea to realize this use case was creating a "service account" in Kill Bill, having all available "shell" payment methods. Then all payments would be made by using this same user, without the need of creating a new account for each final user.

I would not go down that road (1:N payment methods where N is very large isn't a great position to be in).

Even if the end user doesn't have a proper "account" for the client application, there is still some form of id that uniquely identifies that customer (since he's paying for *something*). I would create an account tied to that id in that case.

One practical example is when Kill Bill is used as the payment platform for a provider of inflight wifi service (on-demand use-case, not subscription-based). The end customer may not have an account at the provider, but there is something that uniquely identifies him for the duration of the flight (email address, seat number, etc.), as this is needed to switch devices, reconnect, etc. In this case, you would create "on-demand" accounts associated with that id. A frequent flyer might end up with as many as one "on-demand" account by flight taken behind the scenes, but this scales *very* well and is quite easy to manage.

Indeed, my concerns were about this kind of "transactional" payer relations. Thank you so much for the hints, and for the sensible use case! ;) 

Best

--
Alessio Gaeta

( Caravelo (

This message and the documents that may be attached to it are destined exclusively to its recipient(s) and can contain restricted or confidential information. Access to this information by people different from the recipients is not authorized. If your address does not match the recipient(s)'s, or you have received the message by error, we ask you to please communicate it to the sender immediately via email by Reply, and proceed to delete it. Do not use, distribute and/or copy the message or its attachments if you are not the intended recipient.

We further inform you that personal data contained in this document, including contact information, is protected by the European General Data Protection Regulation and other current legislation on the matter of data protection. Caravelo, ChangeYourFlight SL., will process it with the purpose of managing your relation to our business. Data will be kept for the duration necessary to carry out the purposes for which it was collected. In order to enforce your rectification, cancellation, objection or access rights, contact us at gd...@caravelo.com or through regular mail sent to Ronda de Sant Pere 19, 6-4, 08010 Barcelona, Spain.
Message has been deleted

Pierre-Alexandre Meyer

unread,
Jun 21, 2021, 5:57:17 AM6/21/21
to Luis Bragagnolo, Kill Bill users mailing-list
Hi Luis,

The Stripe plugin documentation explains how to integrate with Checkout and Elements:


I hope this helps!

On Fri, Jun 18, 2021 at 3:09 PM Luis Bragagnolo <luisbra...@gmail.com> wrote:
Pierre, that method (https://docs.killbill.io/latest/multi_gateways.html) is for Stripe.JS legacy but Stripe has a new APIs and way to do things and a token like in Stripe.JS is not longer possible. (https://stripe.com/docs/payments)
Do you have some example of how to do it with the new payments?  

Thanks

Luis Bragagnolo

unread,
Jun 21, 2021, 10:50:20 AM6/21/21
to Kill Bill users mailing-list
Thanks Pierre, 
 I followed all the examples, and what I get at the end is "missing StripeHppRequestsRecord for sessionId " I have attached a screenshot of the postman call. Google couldn't find anything related to that error, and there is where I am stuck. I am following this example https://stripe.com/docs/checkout/integration-builder, and What I am trying to do is: 1) redirect and make 1 payment with stripe.redirectToCheckout({ sessionId: session.id }); . (No Problem) 2) Get payment information for a subscription. I am able to pay, I can see on both sides the payment went through, but I am not able to save the information in Kill Bill.
Any help would be appreciated. Thank you!

image.png

Pierre-Alexandre Meyer

unread,
Jun 21, 2021, 10:50:20 AM6/21/21
to Luis Bragagnolo, Kill Bill users mailing-list
[+mailing-list]

Can you confirm the session id exists for that specific tenant? Check the stripe_hpp_requests table.


On Mon, Jun 21, 2021 at 3:23 PM Luis Bragagnolo <luisbra...@gmail.com> wrote:
THanks Pierre, 

 I followed all the examples, and what I get at the end is "missing StripeHppRequestsRecord for sessionId " I have attached a screenshot of the postman call. Google couldn't find anything related to that error, and there is where I am stuck. I am following this example https://stripe.com/docs/checkout/integration-builder, and What I am trying to do is: 1) redirect and make 1 payment with stripe.redirectToCheckout({ sessionId: session.id }); . (No Problem) 2) Get payment information for a subscription. I am able to pay, I can see on both sides the payment went through, but I am not able to save the information in Kill Bill.
Any help would be appreciated. Thank you! image.png


--
Pierre

Luis Bragagnolo

unread,
Jun 21, 2021, 10:56:36 AM6/21/21
to Kill Bill users mailing-list
Pierre, the session ID is the one that Stripe generated, when you ask if " Can you confirm the session id exists for that specific tenant? " Do you mean that I should add the Stripe Session ID to the tenant somehow first?

Thanks

Pierre-Alexandre Meyer

unread,
Jun 21, 2021, 11:07:45 AM6/21/21
to Luis Bragagnolo, Kill Bill users mailing-list
Hi Luis,

You must generate the sessionId in Kill Bill first: https://github.com/killbill/killbill-stripe-plugin#using-stripe-checkout (steps 2. and 3.)

To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/ceef2489-eae6-47b2-aa30-b91c90416febn%40googlegroups.com.


--
Pierre

Luis Bragagnolo

unread,
Jun 21, 2021, 11:18:49 AM6/21/21
to Kill Bill users mailing-list
I see where is my confusion now.
 I was following the stripe example and I was using a session_ID generated with the Stripe library and not with the API call to Kill Bill.
Thanks Pierre, I will keep working on this, and if it works I will share the Source Code here in case somebody has a similar question.
Thanks again!
Reply all
Reply to author
Forward
0 new messages