Bei der Entwicklung eines neuen Webdienstes konnte ich nicht viele Informationen darüber finden, wie Unternehmen ihre Webdienste abrechnen.
Rechnen Sie auf Anfrage oder nur bestimmte Anfragen ab, zB) GET oder POST?
- Werden diese auf Anwendungs- oder Serverebene verfolgt?
Rechnen Sie nach Bandbreite?
- Wie würde dies für jeden Benutzer nachvollzogen werden?
Berechnen Sie ein Abonnement, um einfach Zugang zu haben?
-dies geht davon aus, dass ihnen erst nach erfolgter Bezahlung ein api-Schlüssel gewährt wird.
Eine Kombination der obigen oder anderer Optionen?
Danke für Ihre Hilfe.
Wie alle Dinge in einer Marktwirtschaft, ist der Preis, aber auch die Unannehmlichkeit (oder Bequemlichkeit) und das Risiko der tatsächlichen Zahlung (unabhängig von der Menge) eine Funktion davon, wie einzigartig und cool und geschätzt Ihre Dienstleistung oder Ihr Produkt ist .
Es ist daher unmöglich, die Frage zu beantworten, sondern sehr allgemein, d. h. in Form von Vorschlägen. Ihr tatsächliches Fakturierungsmodell kann auf einem oder mehreren der folgenden Kriterien basieren:
Im Allgemeinen sollten der Preis und die Modalitäten der Rechnungslegung für beide Parteien fair sein, insbesondere für den Käufer, und in der Regel gilt: je einfacher, desto besser. Der Preis sollte nicht unbedingt niedrig sein, vorausgesetzt, Sie können nachweisen, dass die erbrachte Dienstleistung tatsächlich wertvoll ist und dass Sie entweder investiert und ein Risiko eingegangen sind, um die Dienstleistung einzuführen, oder die laufenden Kosten für die Erbringung der Dienstleistung offensichtlich sind / p>
Ich denke, es hängt davon ab, was der Dienst tut. Im Großen und Ganzen würde ich sagen, Sie sollten Rechnung begleichen, wenn Sie einen inneren Wert bieten. Wie Sie feststellen, was dieses Abrechnungskriterium ist, ist ziemlich domänenspezifisch. Es kann eine Eigenschaft des Dienstes geben, die Ihnen erlaubt zu bestimmen, wie viel Rechnung zu stellen ist.
Angenommen, Sie haben einen Web-Service, der eine Berechnung durchführt. Sie können entscheiden, dass Sie für jede erfolgreiche Berechnung eine feste Gebühr erheben, sagen wir %code%.01 , aber lassen Sie die Benutzer aus, wenn es ein Validierungsproblem gibt, wie eine ungültige Anfrage. Wenn diese Berechnungen vage lang andauernd sind, verfügen Sie möglicherweise über ein Abrechnungsmodell, das auf einer bestimmten CPU-Zeitmetrik basiert.
Ihr Punkt in Bezug auf Abonnements ist gut, und dies ist ein Bereich, in dem Sie potenziell davon profitieren könnten, ein paar kommerzielle Modelle zuzulassen; eine für die Benutzer, die viele Anfragen pro Monat ausführen können, wobei in diesem Fall ein festes Abonnement sinnvoll sein könnte, und eines für Benutzer, die einige Ad-hoc-Anfragen stellen. Im letzteren Fall, natürlich, wenn Sie nur diese Kunden anlocken, werden Sie keine gute Rendite machen. Irgendeine Art von Mittelweg, wobei Sie ein kleines Abonnement haben, aber dann Kunden erlauben, ein "Block" oder "Bündel" von Anfragen oben ohne zusätzliche Verarbeitungskosten zu kaufen, könnte funktionieren.
Die meisten Webservices, die ich kenne, sind für zwei Dinge kostenlos:
Ich habe wirklich keine Projekte mit Pay-for-Performance- oder Pay-per-Hit- / Access-Modellen gesehen oder an ihnen teilgenommen, da es sehr schwierig ist, sie zuverlässig zu berechnen und den Kunden sehr schwer zu erklären, selbst wenn Sie sie verwenden abgestufte oder gebänderte Bereiche. Wie sagen Sie Ihren Kunden, wie viele Treffer sie verwendet haben, insbesondere in einem verteilten System, mit redundanten Fail-Over, etc. Wenn ich $ 0,01 Cent pro Zugang bezahlen müsste, würde ich genau wissen wollen, wie es gemessen wurde, und was das Unternehmen hatte den Zugang zu kontrollieren, und wie genau ihre Überwachung war, etc.
Es ist nicht unmöglich und kann definitiv gemacht werden und funktioniert möglicherweise in großen Massenszenarien.
Viele von denen, die ich gesehen habe, rechne ich nach Zeit, zum Beispiel auf monatlicher oder jährlicher Basis. Einige erlauben es Ihnen, im Laufe des Monats zu zahlen, einige erfordern einige (oder alle) der Gebühr im Voraus. Der Zugriff kann eingeschränkt werden, indem ein Sicherheitszertifikat für den Webdienst ausgestellt wird, das abläuft, wenn das Konto des Kunden abläuft, oder möglicherweise, dass sie eine Client-ID senden und den Server prüfen lassen, ob diese Client-ID eine Antwort haben darf (aber offen für Leute, die die Client-ID einer anderen Person stehlen;)).
Ich nehme an, wenn Sie einen Dienst haben, der sehr große Datenmengen sendet und empfängt, kann es sinnvoll sein, pro Dienstanforderung eine Rechnung zu erstellen, aber die Abrechnung dafür könnte komplizierter werden. Werden die Kunden wahrscheinlich Dutzende Anfragen pro Tag oder nur wenige Anfragen stellen? Wie viel pro Transaktion? 100 $? $ 0.01? Das alles würde von der Art des Dienstes abhängen. Wenn Sie diese Route verwenden möchten, müssen Sie wahrscheinlich sicherstellen können, dass die Clients nur für erfolgreich beantwortete Anforderungen in Rechnung gestellt werden (ich hasse es, eine Rechnung zu erhalten, obwohl meine Client-App die gesamte Web-Service-Nachricht nicht erhalten hat) Ihr Server).
Pro Anfrage oder als Abonnement, und ja, Bandbreite kann eine Variable sein, mit der die Gebühr festgelegt wird. Abhängig vom Wert der Bindung an den Kunden oder der Nutzung einer Vielzahl von lose gekoppelten Kunden. Es gibt keine richtige Antwort auf die Frage, die zu allen oder den meisten Fällen passt.
Wenn ich mir die Dienste anschaue, die ich in der Vergangenheit gemacht habe, wäre das Abonnementmodell das beste zu verwendende Modell. Manchmal scheint ein Tick von $ pro Anfrage der beste Ansatz zu sein, aber ich habe noch nie einen Service auf diese Art konfiguriert.
Ich stimme dem zu, was Rob und Des gesagt haben. Eine Sache zu erinnern ist, dass ein Abonnement ein wirklich einfaches Konzept ist, an das jeder gewöhnt ist und mit dem es sich gut auskennt (wenn Sie es richtig bewerten). Wenn Sie ein breites Publikum abdecken möchten, sehen Sie sich die Zahlungsanbieter an - sie haben leicht unterschiedliche Zahlungsmethoden, je nachdem, wie viele Transaktionen Sie pro Jahr durchführen. Es wird ein festes Abonnement plus eine Gebühr pro Transaktion geben, und beide variieren mit der Anzahl der Transaktionen. Dies ist am flexibelsten, aber es hängt davon ab, ob es für Ihr Geschäft sinnvoll ist.
Tags und Links web-services billing