This was probably asked many times here, but I'm not finding any because I'm not sure what to look for.

I'm developing a simple payment gateway, where partners (consumers) can submit requests so their users can pay and return back.

I will give partners a public key (bound to their domain name), they will use this key on their website (through a script src tag on iframe) to acquire an access token. This access token will be then used to submit requests to my payment gateway.

Question is: what is the technical term in security for what I'm trying to do? And what other methods are there?

Extra info: I have checked how Paypal implements their Buy/Subscribe/Donate buttons, they don't seem to put any sensitive info in the iframe (of the button), how can they make sure of the partner?

Additional note: I don't want my partners to do a server to server call, I want the integration to be very simple from their side.

  • 1
    I notice you keep using the term public key as if it's useful for authentication. It isn't because by definition it is public information. Only a private key can be used for authentication with any confidence whatsoever that it identifies a unique user. Look into PKI, digital certificates, asymmetric encryption, etc.
    – Kyle
    Commented Apr 30, 2013 at 22:07

2 Answers 2


There's a little detail here on how Paypal issue Application IDs for issuing on servers which will host applications making API calls to PayPal on behalf of merchants/service providers - https://www.x.com/developers/paypal/documentation-tools/going-live-with-your-application#register

The approach you're taking above is similar so it's a way of providing client side authentication to the server gateway.

An alternate way to do this would be to issue certificates which you populate with details of the client you're issuing the certificates to. They would then install the certificates on their web servers so those certs would authenticate to your server-side cert.

The immediate issue with the above appears that if someone gets access to the public key your client stores in a script src tag, your client can be impersonated and be given an access token... As such, perhaps the authentication should be abstracted from the published, accessible code.

  • your client can be impersonated, but that's why i will generate an access token from the request IP, which is whitelisted, and make sure all requests later come from the same place.
    – mohdajami
    Commented Apr 30, 2013 at 20:48

This is often known as a service or API key. You are trying to setup a web service. Generally, the client site will submit a request for some action to be done with a publicly shareable identifier that lets your system identify who sent the traffic your way. It should likely be paired with a private code that is used for your server to respond back to your client in a way that lets you confirm to them that you have done whatever they requested (along with details of the request so they can verify their customer didn't change it).

For example, User Bob could go to Client BuyStuff.Com's site and goes to make a purchase. The amount of the purchase and an order number could be sent with BuyStuff's public API key 1234567 to your site. Your site would then know it needs to prompt Bob for payment and would know that it is going to BuyStuff's account. When Bob finishes, you can encrypt the amount paid and the order number and send it back to BuyStuff using BuyStuff's private API key so that BuyStuff knows that the order was successfully paid.

  • Thanks, good example. So, if I use the public key to generate a one time access token (which includes info about partner) do you think it's secure enough?
    – mohdajami
    Commented Apr 30, 2013 at 20:46
  • @medopal You don't use the public key for anything because it isn't really a key in the cryptographic sense. It's basically the machine equivalent of a username. The only purpose it serves is to tell you who the transaction belongs to. If you want to ensure that it is actually coming from the client, you could have the system require an additional step where the order details are required to be encrypted by BuyStuff's server using the private API key, but in general, there isn't any advantage to someone trying to fake who is being paid as Bob is going to see who they are paying. Commented Apr 30, 2013 at 20:53
  • So say that I attacked BuyStuff's handoff of Bob to your server. The best I could do is say that rather than BuyStuff, Bob is trying to buy from BuyOtherStuff. Then when you display the order page for BuyOtherStuff, Bob will realize that something isn't right and not move forward. The important part is making sure that your communication back to BuyStuff to tell them Bob's order is finished is protected so that Bob can't tell BuyStuff that he paid without actually paying you. Commented Apr 30, 2013 at 20:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .